[ClusterLabs] Disabling stonith in Pacemaker 2.0 (was: Re: Pacemaker 1.1.18 deprecation warnings)

[Ken Gaillot]

On Mon, 2017-09-18 at 13:53 -0400, Digimer wrote:
> On 2017-09-18 01:48 PM, Ken Gaillot wrote:
> > As discussed at the recent ClusterLabs Summit, I plan to start the
> > release cycle for Pacemaker 1.1.18 soon.
> > 
> > There will be the usual bug fixes and a few small new features, but
> the
> > main goal will be to provide a final 1.1 release that Pacemaker 2.0
> can
> > branch from.
> > 
> > As such, 1.1.18 will start to log deprecation warnings for syntax
> that
> > is planned to be removed in 2.0. So, we need to decide fairly
> quickly
> > what we intend to remove.
> > 
> > Below is what I'm proposing. If anyone feels strongly about keeping
> > support for any of these, speak now or forever hold your peace!
> > 

<snip>

> > * cluster properties that have been obsoleted by the rsc_defaults
> and
> > op_defaults sections
> > ** stonith-enabled or stonith_enabled (now "requires" in
> rsc_defaults)

<snip>

> Andrew announced that disabling stonith will put a node into
> maintenance
> mode. This should be announced/alerted as well, eh?

My current plan is to remove the stonith-enabled option entirely, so
there will be no stonith-enabled=false anymore.

Users will still have a way to disable fencing, by (ab)using the
"requires" resource meta-attribute. This is a per-resource option
rather than cluster-wide (though it can be applied to all resources
using rsc_defaults).

I don't plan on preventing people from running only resources with
requires=quorum or requires=nothing, without any fencing configured.
However we will probably start tracking whether at least one resource
has requires=fencing, and require that at least one enabled fencing
device be configured if so. If fencing is not available in such a case,
we could put the cluster into maintenance mode, or log a warning and
block when fencing is needed.
-- 
Ken Gaillot <kgaillot at redhat.com>