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

[Yan Gao]

Hi all,

First thanks for bringing this up, Aleksei.

On 11/26/19 3:38 PM, Aleksei Burlakov wrote:
> Dear Developers,
> 
> I would like to raise a discussion about an issue/feature about the 
> maintenance property applied to different levels of a cluster.
> 
> In order to explain the problem lets consider several examples.
> 
> *Scenario 1*. There is a primitive p1 in a group g1. When applying the 
> maintenance property to them, the most specific resource will take 
> precedence. Namely, if p1 has the maintenance property set, it will be 
> used, otherwise, the maintenance property of the g1 is used. It's ok.
> 
> *Scenario 1*. There is a clone of a group c1, group g1, and a primitive 
> p1, that belongs to the group g1. When we apply the maintenance 
> attribute, the most specific attribute takes precedence, but the 
> attribute of the clone c1 may have different value than the group and 
> the primitive. It's strange, but still ok.
> 
> *Scenario 3*. There is a cluster with one node node1 and one primitive 
> p1. This time when setting the maintenance/maintenance-mode attribute to 
> the primitive/node1/default-property the p1 will be true when either one 
> of them is set to true. It means the most specific attribute don't 
> precede anymore. One may think it's the feature, but imho its a *bug*.
> 
> *Scenario 4*. There is only a primitive p1. We apply  both: an 
> is-managed attribute and maintenance attribute This is it will work as
>          is-managed        maintenance        |               p1
>               false                      false                |        
>   unmanaged
Since it seems that "maintenance" attribute tends to takes precedence 
over "is-managed" attribute, this combination probably is the only 
problematic case. I think it probably needs an "else" in here:

https://github.com/ClusterLabs/pacemaker/blob/master/lib/pengine/complex.c#L531

:-)

>               false                      true                 |        
>   unmanaged
>               true                       false                |        
>   managed
>               true                       true                 |        
>   unmanaged
> that works quite unexpectedly.
> 
> In the more complex scenarios, where the is-managed property is used 
> together with the maintenance, the status resources get unpredictable, 
> which is definitely *not ok*.
> 
> The *counterargument* is that it was always like this and the customers 
> are used to this behavior. They may remember that a certain combination 
> of attributes leads to a certain status and enforcing the most specific 
> rule would lead to the *change of behaviour and backward incompatibility*.

Despite how the conflicting attributes/settings should be handled 
correctly at resource levels, I think one main question here probably is:

Should maintenance mode of node/cluster scope consider any specific 
conflicting settings of resources? Or should it just put the whole scope 
(node/cluster) into maintenance mode without exceptions, as how it is now?

Regards,
   Yan

> 
> Please share your opinion about the issue, if we should leave it working 
> as is or enforce the most specific rule in though the whole cluster. And 
> give a priority to either one of the conflicting attributes (is-managed 
> vs maintenance).
> 
> Best regards,
> Aleksei Burlakov
> SUSE Senior Developer
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/developers
> 
> ClusterLabs home: https://www.clusterlabs.org/
>