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

[Ulrich Windl]

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

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

Regards,
Ulrich

> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org 
> http://lists.clusterlabs.org/mailman/listinfo/users 
> 
> Project Home: http://www.clusterlabs.org 
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf 
> Bugs: http://bugs.clusterlabs.org