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/ > _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/developers ClusterLabs home: https://www.clusterlabs.org/