>>> Andrei Borzenkov <arvidj...@gmail.com> schrieb am 11.01.2018 um 12:41 in
Nachricht
<caa91j0waoqg46434gvvz_8yw5ve09fqhshqp-vqjo7uv6fe...@mail.gmail.com>:
> On Thu, Jan 11, 2018 at 10:54 AM, Ulrich Windl
> <ulrich.wi...@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@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
_______________________________________________
Users mailing list: Users@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
