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

Aleksei Burlakov aburlakov at suse.com
Tue Nov 26 09:38:17 EST 2019


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
             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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20191126/4d36d622/attachment.html>


More information about the Developers mailing list