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

Ken Gaillot kgaillot at redhat.com
Fri Jan 26 18:17:27 EST 2018


On Fri, 2018-01-26 at 23:30 +0100, Jehan-Guillaume de Rorthais wrote:
> On Fri, 26 Jan 2018 09:37:39 -0600
> Ken Gaillot <kgaillot at redhat.com> wrote:
> ...
> 
> > > 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.)
> 
> That makes me wonder how pcs and crm syntax should evolve as well
> from the
> user point of view... :/ 

I'm sure they'll adapt similarly, allowing the old names for backward
compatibility.

> > > > "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".
> 
> What about my previous suggestion to use "active" to match either
> "Started" or
> "Promoted" state?

I like it. My only concern is how difficult it might be to work with
old configurations. (Pacemaker 2.0 will guarantee rolling upgrades from
1.1.11 and later, and full-stop upgrades from 1.0.0 and later.)

In other words, if someone has an older configuration with target-
role="Started", we'd want to automatically remap that (via XSLT) to
"active", but if it's a newer configuration, we wouldn't want to touch
that. It's feasible but confusing, even more so when considering
pcs/crm/etc., which would need to figure out the user's intent (the
user likely doesn't know which CIB schema version they're using) and
map it one way or the other depending on the CIB schema, or upgrade the
CIB schema first.

Using one-to-one new terms for master and slave would be a lot easier
to implement.

I think we're at least converging on "promotable" to describe the
resources and "promoted" for the master role. For 2.0.0, the only
change will likely be the <master> tag and some documentation, so we
can proceed on that basis.
-- 
Ken Gaillot <kgaillot at redhat.com>




More information about the Users mailing list