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 ...
+1 > But indeed, documentation definitely makes lot of sense. +1 > Based on the whole idea, an inconsistent logic is in here then: > > https://github.com/ClusterLabs/pacemaker/commit/9a8cb86573#diff-b4b7b0fdcefcd3eb5087dfbf0d101ec4R471 > > 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 acting) - 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 they like... 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 pacemaker project). [*] 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 altogether :-) -- Jan (Poki)
pgpM3wkYxXGpS.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/
