[ClusterLabs] (Not) Coming in 1.1.18: deprecating stonith-enabled

[Ken Gaillot]

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 <kgaillot at redhat.com>