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

[Kristoffer Grönlund]

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.

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.

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

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.

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

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