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

[Ulrich Windl]

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 16.01.2018 um 23:33 in Nachricht
<1516142036.5604.3.camel at redhat.com>:
> 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.

If there will be exactly two states, it'll be bi-state resource, and when abandoning the name, you should also abandon names like promote and demote, because they stick to master/slave.
So maybe start with describing what a stateful resource is, then talk about names.
BTW: All resoiucres we have are "stateful", because they can be in started and stopped states at least ;-)


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

See above.

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

Still describe the model first, then talk about names. Are there two resources with just two roles, or an there be more than two resources with more than two roles?

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

I'd like to see a good description of the overall clone mechanisms, too.


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

To change anything because of the _word_ "slave" is absolute nonsense IMHO. Next would be "servant", I guess, and then "server".

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

"subordinate" maybe, but there is a probability that fewer people understand what it means.

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

"execute" is also a bad word ;-) Maybe just "perform" ;-)

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

Regards,
Ulrich


> -- 
> Ken Gaillot <kgaillot at redhat.com>
> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org 
> http://lists.clusterlabs.org/mailman/listinfo/users 
> 
> Project Home: http://www.clusterlabs.org 
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf 
> Bugs: http://bugs.clusterlabs.org