Well, this turned out to be trickier than initially imagined. It's actually related to a broader issue in the policy engine that has only been addressed piecemeal, which is that we need to make sure the learning of a given piece of information happens before there is a need to use it.
To properly deprecate stonith-enabled, we'll have to move more of the information-gathering to the beginning of the policy engine's process. As part of that, I'll probably try to define more clearly the information that can be relied on at any given point. In any case, that's a bigger project than the 1.1.18 (or 2.0.0) time frame. On Mon, 2017-09-25 at 18:53 -0500, Ken Gaillot wrote: > Hi all, > > I thought I'd call attention to one of the most visible deprecations > coming in 1.1.18: stonith-enabled. In order to deprecate that option, > we have to provide an alternate way to do the things that it does. > > stonith-enabled determines whether a resource's "requires" meta- > attribute defaults to "quorum" or "fencing". This already has an > alternate method, the rsc_defaults section. > > For everything else, e.g. whether to fence misbehaving nodes, and > whether to start resources when fencing hasn't been configured, the > cluster will now check additional criteria. > > This my plan at the moment: > > Fencing will be considered possible in a configuration if: "no- > quorum- > policy" is "suicide", any resource has "requires" set to "unfencing" > or > "fencing" (the default), any operation has "on-fail" set to "fence" > (the default for stop operations), or any fence resource has been > configured. > > If fencing is not possible, the cluster will behave as if stonith- > enabled is false (even if it's not). -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Users mailing list: Users@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org