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

[Jehan-Guillaume de Rorthais]

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

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