[ClusterLabs Developers] [deveoplers] maintenance vs is-managed; different levels of the maintenance property
jpokorny at redhat.com
Tue Dec 17 20:36:52 EST 2019
On 28/11/19 11:36 +0000, Yan Gao wrote:
> On 11/28/19 1:19 AM, Ken Gaillot wrote:
>> There is some room for coming up with better option naming and
>> meaning. For example maybe the cluster-wide "maintenance-mode"
>> should be something like "force-maintenance" to make clear it takes
>> precedence over node and resource maintenance.
> Not sure if renaming would introduce even more confusion ...
> But indeed, documentation definitely makes lot of sense.
> Based on the whole idea, an inconsistent logic is in here then:
> We should probably remove the "else" there, so that cluster-wide
> maintenance-mode=true ALWAYS takes precedence.
> Currently there's a corner case:
> * Cluster maintenance-mode=true
> * Resource is-managed=true
> * Resource maintenance=false
> , which makes an exception that the resource will be "managed".
ouch, slight +1 (oh, these least-surprise concerns where it verges
on least surprise towards existing reliance vs. newcomers, those
are clearly in a mutual contradiction, making it tough, not for
the first time).
Anyway, sorry for picking this is as an exemplary showcase (we all
are learning as we can, nobody is born with experience, but since
we are at the dev list, and we are not used to some in-community
retrospectives (yet?) slash meta-talk about approaches exactly to
take away something, please forgive, it has nothing to do with who,
just what) of how we shall _not_ be extending pacemaker, since
what seemed a simple, straightforward and justified addition of
a new configuration toggle carries, in hindsight, a lot of hidden
costs that were not forseen at that time:
- most notably that there are now two competitive options, one
being the specialization (expressible with a combination with
other configuration steps!) of other established option
(correct me if I am wrong)
- based on the above, any human or machine needs to perform two
step check (easy to miss) to be reasonably sure some claim
holds or not (that the resource will be part of the cluster
- based on the above, increase of redundance/burden, plus
maintenance costs not just at pacemaker itself (more complex
codebase) but also any external tooling incl. higher level tools
(ditto, plus ensuring the change is caught by these at all[*]),
confusion on combinability, etc.
There are bounds to evolution of code if there's some responsibility
behind it, let's keep up on sustainability (in all directions if
possible). Suggested renaming would be a misstep in that regard
as well, I think. High-level tools can abstract it whatever way
Speaking of these (I think they are still rather mid-level tools,
there is an enormous space for improvement in them when they dettach
from trying to carry 1:1 mapping to low level bits and move closer to
user-oriented concepts, otherwise it feels like using plain TeX
forever when it was shown that user-oriented simplification like
LaTeX can go far beyond, still benefitting the universality aspect
of the former) and their advent, I think it's fully OK to resist
urges to combine existing primitives in some composite way unless
there's a clear blocker (risk of race conditions, for instance).
These combinations shall occur higher up, outside (there were some
"middleware" ideas in the talks previously, not sure where it went,
but given a contract on the API, it well could be outside the
[*] for instance, I missed that change when suggesting the equivalent
to pcs team: https://bugzilla.redhat.com/show_bug.cgi?id=1303969
but hey, they made do avoiding that configuration addition
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Developers