[ClusterLabs] Antw: Changes coming in Pacemaker 2.0.0

[Kristoffer Grönlund]

Andrei Borzenkov <arvidjaar at gmail.com> writes:

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

The problem is really that the configuration is declarative and that in
the declarative configuration there is a hierarchy of attributes that
combine in more or less obvious ways. There is no way to retain that and
not create pitfalls. At least the CIB is not CSS...

In this case, the place where things went wrong was when crmsh left
"managed=yes" in place instead of relying on the default and just
unsetting the managed attribute.

Though there's a similar confusion when setting target-role - the
command line gives the impression of imperative commands; "start this,
stop that" while the actual instructions issued to pacemaker are
declarative. It gets especially tricky when target-role is set on a
group as well as on individual resources in the group.

Unhelpful perhaps, but in my opinion, the CIB makes it very difficult to
answer even simple questions like "what value does this attribute really
have", and for very marginal benefit. If it were up to me, rule
expressions, op_defaults, rsc_defaults, nested resources (group,
master, clone) and multiple meta_attribute/attribute elements for single
resources would all be deleted. The only real valid case I can see for
rule expressions is for configuring different attribute values for
different nodes - and that would be better achieved by fetching the
value from a distributed database which handles that part. Having such a
database would also enable things like private data / passwords to be
kept out of the CIB.

Cheers,
Kristoffer

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

-- 
// Kristoffer Grönlund
// kgronlund at suse.com