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

[Ken Gaillot]

On Fri, 2018-01-26 at 09:07 +0100, Jehan-Guillaume de Rorthais wrote:
> On Thu, 25 Jan 2018 15:21:30 -0500
> Digimer <lists at alteeve.ca> wrote:
> 
> > On 2018-01-25 01:28 PM, Ken Gaillot wrote:
> > > On Thu, 2018-01-25 at 13:06 -0500, Digimer wrote:  
> > > > On 2018-01-25 11:11 AM, Ken Gaillot wrote:  
> > > > > On Wed, 2018-01-24 at 20:58 +0100, Jehan-Guillaume de
> > > > > Rorthais
> > > > > wrote:  
> > > > > > 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.

Doh! I forgot that there is a key difference between "started" and
"slave". If you set target-role="Started" for a multistate clone,
Pacemaker is allowed to bring it up in master or slave mode, whereas
specifying "Master" or "Slave" specifically only allows that one role.

So, we can't use "started" to replace "slave".

> > > > > > > 
> > > > > > > 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.  
> > > > > 
> > > > > Zeroing in on this question, which does everyone prefer:
> > > > > 
> > > > > * "Binary clones" (in the sense of "one of two roles", but
> > > > > not very
> > > > > obvious)
> > > > > 
> > > > > * "Stateful clones" (potentially confusing with anonymous vs
> > > > > unique
> > > > > clones, and all resources have state)
> > > > > 
> > > > > * "Multistate clones" (less confusing with anonymous vs
> > > > > unique, and
> > > > > already in current use in documentation, but still all
> > > > > resources
> > > > > have
> > > > > multiple possible states)
> > > > > 
> > > > > * "Promotable clones" (consistent with "promote" theme, but
> > > > > the
> > > > > word
> > > > > looks odd, and confusing with whether an individual instance
> > > > > is
> > > > > eligible to be promoted)
> > > > > 
> > > > > * "Promotion clones" (also consistent, but sounds odd and not
> > > > > particularly obvious)  
> > > > 
> > > > I don't want to push my preferences here, but I wanted to
> > > > suggest
> > > > that
> > > > something that sounds a bit on now will sound normal over time.
> > > > 
> > > > I will point out, though, that spell check doesn't complain
> > > > about
> > > > 'Binary' and 'Promotion'.
> > > > 
> > > > If I can throw another suggestion in (without offering
> > > > preference for
> > > > it
> > > > myself), 'dual-state clones'? The reasoning is that, though
> > > > three
> > > > words
> > > > instead of two, spell-check likes it, it sounds OK on day one
> > > > (from a
> > > > language perspective) and it reflects that the clone has only
> > > > one of
> > > > two
> > > > states.  
> > > 
> > > Or "dual-role".
> > > 
> > > Binary/dual/multi all have the issue that all resources have
> > > multiple
> > > states (stopped, started, etc.). Not a deal-breaker, but a factor
> > > to
> > > consider.
> > > 
> > > What we're trying to represent is: clone resources that have an
> > > additional possible role that pacemaker manages via the
> > > promote/demote
> > > actions.
> > > 
> > > I go back and forth between options. "Multistate" would be OK,
> > > especially since it's already used in some places. "Promotable"
> > > is
> > > probably most accurate.  
> > 
> > If the thing only has two states; "dual-role" is perfect. If the
> > thing
> > can have 3+ states, "multistate" is perfect.
> 
> In 1.1.x, there is exactly three states: stopped, started, promoted.
> In 1.1.x, there is exactly two roles: slave and master.
> 
> Using this terminology, "dual-role" would make sense. However, note
> that
> "target-role" could be set to "Stopped", which is actually a state :/
> 
> If we pick "stopped", "started" and "promoted" as new terminology,
> there's no
> more distinction between states and role. We only have three states. 

"State" is not really a specific technical term in Pacemaker. Depending
on the context, "state" could also be stopping, starting, failed, etc.

"Role" is used more consistently, as in "target-role" or "role" in
constraints. It can only be "Started", "Stopped", "Slave", "Master".

> All RA
> must implement the first two states "stopped" and "started". The
> cases where RA
> is promotable should then be called..."promotable" I suppose.
> 
> However, why exactly should we find a terminology for RA implementing
> the
> "promote" action? Should we find some new terminology for RA
> implementing
> optional actions like "notify" ("notifiable") or "validate-all"
> ("validatable")
> action as well? (ok, these are not roles, but I try to explain my
> point :))
> 
> Now the terminology is common using "stopped, started, promoted",
> should we stop considering "multistate RA" as special cases? We could
> simply
> explain RAs are implementing all or a subset of the actions/roles
> Pacemaker
> offers and give documentation details related to roles properties,
> variables
> and transitions, isn't it?

We will need some way of specifying it in the syntax, and that will
become its name ... <clone promotable="true"> or whatever. (We can't
simply go by what's in the RA metadata for technical reasons not worth
going into here.)

> Considering the following documentation page, this would means
> merging chapters
> 10.2 and 10.3 inside chapter 5.
> 
> 
> > "Promotable" is certainly accurate, but I have a (very mild)
> > concern
> > about how easily it is understood by non-native English speakers.
> > Perhaps someone who speaks English as a second language could chime
> > in
> > on that?
> 
> "Promotable" sounds accurate to me (native french speaker).

That's good to know. I think we have at least narrowed it down to
"multistate" or "promotable" :-)

Unfortunately the role names are now back in play as well. "Promoted"
and "unpromoted"?

E.g.:

Instead of a single "started" role, a promotable clone resource must be
in one of two roles when active: "promoted" or "unpromoted".
-- 
Ken Gaillot <kgaillot at redhat.com>