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

Wed Jan 24 14:58:54 EST 2018

On Wed, 24 Jan 2018 13:28:03 -0600
Ken Gaillot <kgaillot at redhat.com> wrote:

> I think there's enough sentiment for "promoted"/"started" as the role
> names, since it most directly reflects how pacemaker uses them.
> 
> For the resources themselves, how about "binary clones"?

I'm not sure to understand what your question is about.

If it is related to how the RA are designated between the ones able to
promote/demote and the other ones, this does not reflect to me the resource can
be either started or promoted. Moreover, I suppose this kind of resources are
not always binary clones. The states might be purely logical.

Multistate sounds the best option to me. Simple.

If you need some more options, I would pick: clustered resource.

We could argue simple clones might be "clustered resource" as well, but they
are not supposed to be related to each other as a primary/promoted resource and
a secondary/standby resource are.

My 2¢

> On Thu, 2018-01-18 at 10:48 -0600, Ken Gaillot wrote:
> > On Thu, 2018-01-18 at 08:22 +0100, Ulrich Windl wrote:  
> > > > > > Ken Gaillot <kgaillot at redhat.com> schrieb am 17.01.2018 um
> > > > > > 17:04 in Nachricht  
> > > 
> > > <1516205099.5103.3.camel at redhat.com>:  
> > > > On Wed, 2018-01-17 at 08:32 +0100, Ulrich Windl wrote:  
> > > > > > > > Ken Gaillot <kgaillot at redhat.com> schrieb am 16.01.2018
> > > > > > > > um
> > > > > > > > 23:33 in Nachricht  
> > > > > 
> > > > > <1516142036.5604.3.camel at redhat.com>:  
> > > > > > As we look to release Pacemaker 2.0 and (separately) update
> > > > > > the
> > > > > > OCF
> > > > > > standard, this is a good time to revisit the terminology and
> > > > > > syntax
> > > > > > we
> > > > > > use for master/slave resources.
> > > > > > 
> > > > > > I think the term "stateful resource" is a better substitute
> > > > > > for
> > > > > > "master/slave resource". That would mainly be a documentation
> > > > > > change.  
> > > > > 
> > > > > If there will be exactly two states, it'll be bi-state
> > > > > resource,
> > > > > and
> > > > > when abandoning the name, you should also abandon names like
> > > > > promote
> > > > > and demote, because they stick to master/slave.
> > > > > So maybe start with describing what a stateful resource is,
> > > > > then
> > > > > talk
> > > > > about names.
> > > > > BTW: All resoiucres we have are "stateful", because they can be
> > > > > in
> > > > > started and stopped states at least ;-)  
> > > > 
> > > > Good points.
> > > > 
> > > > A clone is a resource with a configurable number of instances
> > > > using
> > > > the
> > > > same resource configuration. When a clone is stateful, each
> > > > active  
> > > 
> > > s/the same/a common/ # if they were the same, there could be no
> > > differences  
> > 
> > Nope, it's identical ... a single <clone>+<primitive> configuration
> > in
> > Pacemaker is used to generate all instances. The service's own
> > configuration doesn't change, either. Each instance is either
> > completely identical, and simply running on different nodes, or
> > handles
> > a subset of requests determined by information available at run-time.
> >   
> > > > instance is in one of two roles at any given time, and Pacemaker  
> > > 
> > > two: just two or at least two?  
> > 
> > Exactly two.
> > 
> > While it is easy to imagine more than two, or even more complex
> > scenarios (e.g. database server instances can serve as master for
> > certain tables and replicant for other tables), we don't see any
> > demand
> > for managing that via pacemaker, and it would require a complete re-
> > implementation (and someone with the resources to do that).
> >  
> > > > manages instances' roles via promote and demote actions.  
> > > 
> > > NOw try to define what promote and demote do ;-)  
> > 
> > A successful call to the resource agent's "start" action must leave
> > the
> > resource in a particular one of the roles (the default role, from the
> > cluster's point of view). A successful "promote" action must move an
> > instance from the default role to the non-default role, and a
> > successful "demote" action must move an instance from the non-default
> > role to the default role.
> > 
> > So, it's very generic from the cluster's point of view.
> >   
> > > > Too bad "roleful" isn't a word ;-)
> > > > 
> > > > As you mentioned, "state" can more broadly refer to started,
> > > > stopped,
> > > > etc., but pacemaker does consider "started in slave role" and
> > > > "started
> > > > in master role" as extensions of this, so I don't think
> > > > "stateful"
> > > > is
> > > > too far off the mark.  
> > > 
> > > Maybe also state the purpose of having different roles here, and
> > > define what a role as opposed to a state is.  
> > 
> > That's part of the problem -- the purpose is entirely up to the
> > specific application.
> > 
> > Some use it for a master copy of data vs a replicated copy of data, a
> > read/write instance vs a read-only instance, a coordinating function
> > vs
> > an executing function, an active instance vs a hot-spare instance,
> > etc.
> > 
> > That's why I like "promoted"/"started" -- it most directly implies
> > "whatever role you get after promote" vs "whatever role you get after
> > start".
> > 
> > It would even be easy to think of the pacemaker daemons themselves as
> > clones. The crmd would be a stateful clone whose non-default role is
> > the DC. The attrd would be a stateful clone whose non-default role is
> > the writer. (It might be "fun" to represent the daemons as resources
> > one day ...)
> >   
> > > > Separately, clones (whether stateful or not) may be anonymous or
> > > > unique
> > > > (i.e. whether it makes sense to start more than one instance on
> > > > the
> > > > same node), which confuses things further.  
> > > 
> > > "anonymous clone" should be defined also, just as unique: Aren't
> > > all
> > > configured resources "unique" (i.e. being different from each
> > > other)?
> > > 
> > > I'm curious about more than two roles, multiple "masters" and
> > > multiple "slaves".  
> > 
> > It's a common model to have one database master and a bunch of
> > replicants, and with most databases having good active/active support
> > these says, it's becoming more common to have multiple masters, with
> > or
> > without separate replicants. It's also common for one coordinator
> > with
> > multiple workers.
> >   
> > > 
> > > Regards,
> > > Ulrich  

-- 
Jehan-Guillaume de Rorthais
Dalibo