On Wed, 26 Feb 2020 19:11:36 +0100 [email protected] wrote: > Ken Gaillot <[email protected]> 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. _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
