[ClusterLabs] Feedback wanted: changing "master/slave" terminology

[Ken Gaillot]

On Wed, 2018-01-17 at 19:59 +0100, Kristoffer Grönlund wrote:
> Ken Gaillot <kgaillot at redhat.com> writes:
> 
> > 
> > I can see the point, but I do like having <clone> separate.
> > 
> > A clone with a single instance is not identical to a primitive.
> > Think
> > of building a cluster, starting with one node, and configuring a
> > clone
> > -- it has only one instance, but you wouldn't expect it to show up
> > as a
> > primitive in status displays.
> > 
> > Also, there are a large number of clone meta-attributes that aren't
> > applicable to simple primitives. By contrast, master adds only two
> > attributes to clones.
> 
> I'm not convinced by either argument. :)
> 
> The distinction between single-instance clone and primitive is
> certainly
> not clear to me, and there is no problem for status displays to
> display
> a resource with a single replica differently from a resource that
> isn't
> configured to be replicated.

There probably isn't much user-visible difference -- the only one I can
think of is that clones have a default stickiness of 1 instead of 0.
Implementation-wise though, there's a huge difference, and I'm not sure
they would behave the same in all cases. In particular I might expect
different behavior when used in constraints with other clones.

But I was assuming you weren't allowing any syntactical difference
between the two. If the syntax can distinguish them, e.g. <primitive
clone=(none|stateless|stateful)>, that wouldn't conflict with the
current implementation.

> The number of meta-attributes related to clones seems irrelevant as
> well, pacemaker can reject a configuration that sets clone-related
> attributes for non-clone resources just as well as if they were on a
> different node in the XML.

I was thinking more in terms of user understandability. To me,
isolating the clone properties is easier to follow (and learn), rather
than mixing them in with primitive properties.

> From the XML perspective, I think the current approach is logically
> > structured, a <clone> wrapped around a <primitive> or <group>, each
> > with its own meta-attributes.
> 
> Well, I guess it's a matter of opinion. For me, I don't think it is
> very
> logical at all. For example, the result of having the hierarchy of
> nodes
> is that it is possible to configure target-role for both the wrapped
> <primitive> and the container:
> 
> <clone>
>  <meta-attributes>
>   <nvpair name="target-role" value="Stopped">
>  </meta-attributes>
>  <primitive>
>   <meta-attributes>
>    <nvpair name="target-role" value="Started">
>   </meta-attributes>
>  </primitive>
> </clone>
> 
> Then edit the configuration removing the clone, save, and the
> resource
> starts when it should have been stopped.

There's nothing preventing that, but as a best practice, I would put
only clone properties in the outermost meta-attributes block.

It might be even better to do away with that block and put those
properties in the tag, e.g. <clone id="clone1" notify="true">. That
would ensure primitive meta-attributes could be set only in the
appropriate spot. It would prevent clone properties from being used in
rules, but they probably shouldn't be anyway.

> It's even worse in the case of a clone wrapping a group holding
> clones of resources, in which case there can be four levels of
> attribute
> inheritance -- and this applies to both meta attributes and instance
> attributes.

Clones can't be members of a group, we did avoid that degree of
insanity. :)

> Add to that the fact that there can be multiple sets of instance
> attributes and meta attributes for each of these with rule
> expressions
> and implicit precedence determining which set actually applies...

That can be confusing, but I think it does offer an important
flexibility for use cases that can't be addressed otherwise, and it's
optional, so anyone who doesn't need it doesn't have to see it.

Combining your suggestion with mine above, I could see putting the
clone tag within the primitive or group, like:

  <primitive id="clone1" ...>
    <clone notify="true"/>
    <meta_attributes> ... </meta_attributes>
    <instance_attributes> ... </instance_attributes>
  </primitive>

but neither that nor your suggestion would allow us to (easily) prevent
a clone from being inside a group or bundle. The relationship that
needs to be expressed is:

  primitives can be grouped, cloned, or bundled
  groups can be cloned but not grouped or bundled
  clones and bundles cannot be grouped, cloned, or bundled

A lesser concern would be that we would have to continue to support the
 old syntax in order not to break rolling upgrades, since it probably
wouldn't be possible to automatically transform it to the new syntax.

Then there's the goal of releasing 2.0.0-rc1 this month, which is
doable with <master> -> <clone stateful="true"> but not with a major
new project like this :)
-- 
Ken Gaillot <kgaillot at redhat.com>