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

[Adam Spiers]

Digimer <lists at alteeve.ca> wrote:
>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.

Mine too based on a first reaction.

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

"Standby" tends to imply that it's doing nothing, which isn't really
the case.  But yeah, good to consider as many options as possible
before making a decision :-)

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

Amen.