[ClusterLabs] Antw: Re: Antw: Changes coming in Pacemaker 2.0.0

[Ken Gaillot]

On Thu, 2018-01-11 at 12:52 +0100, Ulrich Windl wrote:
> > > > Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 11.01.2018 um
> > > > 12:41 in
> 
> Nachricht
> <CAA91j0WAOQg46434gVvz_8Yw5VE09FQHshQp-vQjo7uV6fezbA at mail.gmail.com>:
> > On Thu, Jan 11, 2018 at 10:54 AM, Ulrich Windl
> > <Ulrich.Windl at rz.uni-regensburg.de> wrote:
> > > Hi!
> > > 
> > > On the tool changes, I'd prefer --move and --un-move as pair over
> > > --move and --clear 
> > 
> > ("clear" is less expressive IMHO).
> > 
> > --un-move is really wrong semantically. You do not "unmove"
> > resource -
> > you "clear" constraints that were created. Whether this actually
> > results in any "movement" is unpredictable (easily).
> 
> You undo what "move" does: "un-move". With your argument, "move" is
> just as bad: Why not "--forbid-host" and "--allow-host" then?

That's a good point actually. There's a tension between Pacemaker's
model (defining a desired state, and letting Pacemaker decide how to
get there) vs most people's intuition (defining actions to be taken).
Also, Pacemaker's XML syntax tends to be very flexible such that one
expression can convey multiple logical intents. So we see that
discrepancy sometimes in command naming vs implementation.

> 
> > 
> > Personally I find lack of any means to change resource state
> > non-persistently one of major usability issue with pacemaker
> > comparing
> > with other cluster stacks. Just a small example:
> > 
> > I wanted to show customer how "maintenance-mode" works. After
> > setting
> > maintenance-mode=yes for the cluster we found that database was
> > mysteriously restarted after being stopped manually. It took quite
> > some time to find out that couple of weeks ago "crm resource
> > manager"
> > followed by "crm resource unmanage" was run for this resource -
> > which
> > left explicit "managed=yes" on resource which took precedence over
> > "maintenance-mode".
> 
> Oops: Didn't know that!
> 
> > 
> > Not only is this asymmetrical and non-intuitive. There is no way to
> > distinguish temporary change from permanent one. Moving resources
> > is
> > special-cased but for any change that involves setting resource
> > (meta-)attributes this approach is not possible. Attribute is
> > there,
> > and we do not know why it was set.
> 
> Yes, the "lifetime" in a rule should not restrict what the rule does,
> but how long the rule exists. As garbage collection of expired rules
> (which does not exist yet) would have less accuracy as the lifetime
> (maybe specified in seconds), a combination could be used.

Expired rules are still useful -- e.g. for troubleshooting an event
that occurred while the rule was in effect, or for simulating events
that occur inside and outside the effective window.

It would be helpful though to have a new command to remove all expired
rules from the configuration, so an admin can conveniently clean up
periodically.

> Regards,
> Ulrich
-- 
Ken Gaillot <kgaillot at redhat.com>