Hello, wanted to point out one thing that occurred to me when thinking about the paragraph below.
On 8/12/20 8:57 PM, Ken Gaillot wrote:
Similarly, Pacemaker offers the cluster-wide "no-quorum-policy" option to specify what happens to resources when quorum is lost (the default being to stop them). With 2.0.5, "demote" will be a possible value here as well, and will mean "demote all promotable resources and stop all other resources". The intended use case is an application that cannot cause any harm after being demoted, and may be useful in a demoted role even if there is no quorum. A database that operates read-only when demoted and doesn't depend on any non-promotable resources might be an example.
Perhaps not that expected corollary with this cluster-wide setting (only acknowledged when the cluster is upgraded in its entirety?), if I understand it correctly, is that previously promoted resource will get stopped anyway once it depends on a simple resource that doesn't specify "on-fail" on its own (putting global/resource defaults aside). It is this implicit resource "composability" (a.k.a. resource trees, with some tweaks applicable right at this "composed service" level) idea of long declined RGManager (RIP) that is still quite an appealing and natural way (despite having less expressive power in general) one can think of composed services (i.e. the behaviour of a final brings-me-value unit rather than sum of moving parts behind it). Through the prism of this tree model, if it could be proved that no other simple resources share dependency on any of the prerequisites with this promoted resource to be demoted because of "on fail" event, it would be intuitive to expect they will be kept running and hence will prevent this promoted resource from consequentially being stopped despite just a weaker form of its demotion is the first and foremost choice requested by the user. Similarly with clones and other promotable prerequisites, except it might be wise to demote them as well if it would not conflict with demotion of the dependent promoted resource that just suffered a failure. Rationale for this is that prerequisite resource _solely_ consumed by resources that don't need quorum as well hardly needs quorum on its own, otherwise this is a conflicting/fishy configuration in some way. (It would likewise be interesting and configuration-proofing-friendly to investigate such "composing rules of soundness".) I see there are some practical limits to these semi-recursive and potentially explosive graph problems, but there's also a question what's an intuitively expected behaviour, and possible disconnect could at least be addressed in the documentation. [Alternatively, some kind of "back-propagation" (intuitively, "this terminal resource has powers to steer the behaviour of its prerequisites, as the configuration of this terminal resource is what's wanted by the outer surroundings of this box, afterall) flag could be devised such that it would override any behaviour of the prerequisite resources on a subset of conflicting options, like on-fail, given that there is no conflict with any other resource dependent on the same resource.] Thanks & cheers -- poki _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
