[ClusterLabs Developers] [deveoplers] maintenance vs is-managed; different levels of the maintenance property

[Jan Pokorný]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20191218/dd6d6655/attachment.sig>