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

[Ken Gaillot]

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.

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

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

* 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.
-- 
Ken Gaillot <kgaillot at redhat.com>