[ClusterLabs] Antw: [EXT] Coming in Pacemaker 2.0.4: shutdown locks
Jehan-Guillaume de Rorthais
jgdr at dalibo.com
Thu Feb 27 05:05:02 EST 2020
On Wed, 26 Feb 2020 19:11:36 +0100
wferi at niif.hu wrote:
> Ken Gaillot <kgaillot at redhat.com> writes:
> > I think a per-resource option would have more potential to be
> > confusing than helpful. But, it should be relatively simple to extend
> > this as a per-resource option, with the global option as a
> > backward-compatible default, if the demand arises.
> And then you could immediately replace the global option with an
> rsc-default. But that's one more transition (not in the PE sense).
> It indeed looks like this is more a resource option than a global
> one, but the default mechanism provides an easy way to set it
> globally for those who prefer that. Unless somebody wants to
> default it to twice (or so) the resource start timeout instead...
Well, for what it worth, I agree this looks like a per-resource option.
Moreover, this feature seems too focused on one specific use-case, making it
narrow and confusing to make it as automatic as possible. I like the idea of
mirrored actions, enabling AND disabling something few steps later in the same
procedure. It makes it cleaner to understand.
What about something like "lock-location=bool" and
"lock-location-timeout=duration" (for those who like automatic steps)? I imagine
it would lock the resource location (unique or clones) until the operator
unlock it or the "lock-location-timeout" expire. No matter what happen to the
resource, maintenance mode or not.
At a first look, it looks to peer nicely with maintenance-mode and avoid
resource migration after node reboot.
More information about the Users