>>> Jehan-Guillaume de Rorthais <[email protected]> schrieb am 27.02.2020 um 11:05 in Nachricht <20200227110502.3624cb87@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/ _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
