[ClusterLabs] Antw: Re: Antw: [EXT] Coming in Pacemaker 2.0.4: shutdown locks

[Ulrich Windl]

>>> Jehan-Guillaume de Rorthais <jgdr at dalibo.com> schrieb am 27.02.2020 um
11:05 in
Nachricht <20200227110502.3624cb87 at firost>:

[...]
> What about something like "lock‑location=bool" and

For "lock-location" I would assume the value is a "location". I guess you
wanted a "use-lock-location" Boolean value.

> "lock‑location‑timeout=duration" (for those who like automatic steps)? I 
> imagine

I'm still unhappy with "lock-location": What is a "location", and what does it
mean to be "locked"?
Is that fundamentally different from "freeze/frozen" or "ignore" (all those
phrases exist already)?

> 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.

I wonder: Where is it different from a time-limited "ban" (wording also exists
already)? If you ban all resources from running on a specific node, resources
would be move away, and when booting the node, resources won't come back.
But you want the resources to be down while the node boots, right? How can
that concept be "married with" the concept of high availablility? "We have a HA
cluster and HA resources, but when we boot a node those HA-resources will be
down while the node boots." How is that different from not having a HA cluster,
or taking those resources temporarily away from the HA cluster?
(That was my intitial objection: Why not simply ignore resource failures for
some time?)

Regards,
Ulrich

> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> 
> ClusterLabs home: https://www.clusterlabs.org/