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

Digimer lists at alteeve.ca
Wed Jan 17 01:41:51 EST 2018

On 2018-01-16 05:33 PM, Ken Gaillot wrote:
> 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.
> A bigger question is what to call the two roles. "Master" and "Slave"
> would be continue to be accepted for backward compatibility for a long
> time. Some suggestions:
> * master/worker, master/replicant, primary/backup: I'd like to avoid
> terms like these. OCF and Pacemaker are application-agnostic, whereas
> these terms imply particular functionality and are often associated
> with particular software.
> * primary/secondary: Widely used, but sometimes associated with
> particular software.

This has been used by DRBD for some time and it works well. People are
used to it, and it adds consistency with other open source HA projects /
Clusterlabs people.

This is my top choice.

> * promoted with either unpromoted, demoted, default, or started: All
> OCF and Pacemaker actually care about is whether the resource agent has
> been called with the promote action. "Promoted" is good, but the other
> role is less obvious.
> * anything else anyone can think of

For the sake of options; Active / Standby?

> For Pacemaker 2, I'd like to replace the <master> resource type with
> <clone stateful="true">. (The old syntax would be transparently
> upgraded to the new one.) The role names themselves are not likely to
> be changed in that time frame, as they are used in more external pieces
> such as notification variables. But it would be the first step.
> I hope that this will be an uncontroversial change in the ClusterLabs
> community, but because such changes have been heated elsewhere, here is
> why this change is desirable:
> * It is *not about anyone being offended*. It is about making everyone
> feel *welcome* by avoiding emotionally charged language.

The terms are antiquated and loaded. I _strongly_ support changing them.

> * It is *not about victimhood, guilt, blame, or punishment* of any
> particular group. It is about striving for excellence, both in accuracy
> of terminology and in community development.

Recognizing that, though certain words may not have weight for us, but
do for others, is a sign of maturity in the community.

> * The long history of the terms master/slave being used in an
> emotionally neutral context in engineering fields is not a reason to
> continue using them. The concept of slavery *should not* be emotionally
> neutral; it should evoke strong feelings.
> * Slavery is an inaccurate metaphor. The initial intent apparently was
> "a master tells a slave what to do". This is a naive view of slavery.
> Slavery is not an apt comparison to a system harmoniously designed to
> execute tasks efficiently for a common goal. In software, it would be a
> more apt comparison to botnets: something illegally taken from its
> rightful ownership and being forced to perform tasks for its captor.
> * In Pacemaker's particular case, we have long said that master/slave
> resources are simply for resources that can operate in two modes, and
> we don't care what those two modes do or what they are called natively
> by the application. While some applications use master/slave, many have
> moved away from those terms, and others have always used other terms,
> so it makes sense for us to adopt something more generic.

Pacemaker, and HA in general, is/are projects with international reach
used in all parts of the world. It is minor, technically, to change
terminology with the transition to a new major version.

If people have concern about compatibility, there can be support for the
old terms with a deprecation warning, similar to other things being
deprecated as was discussed at the last summit.

Thank you for taking the lead on this. I can speak for Alteeve in saying
we back this 100%.

Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould

More information about the Users mailing list