[
https://issues.apache.org/jira/browse/ACCUMULO-2844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14017273#comment-14017273
]
Christopher Tubbs commented on ACCUMULO-2844:
---------------------------------------------
First, I'd like to point out that "slave" is only unconscionable when it
describes the slavery of humans or suggests that analogy. It is not necessarily
an issue when describing other things, such as machinery or code controlled by
other machinery/code, or metaphors (as in "I'm a slave to my past" or "He's a
slave to his desires" or "She's a slave to chocolate"). It is not *inherently*
an objectionable word. It just has objectionable uses/contexts. As such, I
don't think this proposed change is strictly necessary or useful. In general,
I'm opposed to banning words, especially when there are useful contexts
available for those words.
However, I do understand how even the use of the word could be perceived as
objectionable, due to the way it serves as a historical reminder of atrocities
against human beings, and I'm sensitive to the fact that others have different
perspectives and opinions on this. Since we can make changes that accommodate
those differences, I'm in favor of doing so, to promote a more inclusive and
welcoming community.
That said, I really think "master" is okay to retain. While it does effectively
invoke the connotation of "ownership", it does not need to be "slaves" that are
what is owned. It works in other contexts than that of "slaves", such as
"master of a house", "master of a skill", "master of a degree", etc. In fact,
the "master of a skill" usage is probably the most appropriate to our use of it
anyway, since the master server is really there to perform some specific
specialized functionality, like assignment/balancing, and user operations, more
than it actually controlled the other servers. So, I see no reason to change
"master" at this point, as it's too invasive and largely unnecessary (certainly
not in the bugfix branches, but perhaps in future to be more descriptive in the
specialized functions it provides). I think removing only the "slaves" term
sufficiently addresses the "master/slave" analogy here.
For "slaves", I think simply "tservers" would be appropriate, as proposed.
Changing this terminology mostly involves changing the "slaves" configuration
file, which isn't even really part of Accumulo itself... just some
cluster-management scripts that are shipped with it, and its associated
documentation. This is very superficial change, and satisfies the goals of this
ticket, without being as invasive as changing "master" would be. I think this
change can be done in bugfix branches, so long as the scripts will fall back on
the old "slaves" file for backwards compatibility, if it exists. We can phase
it out in future versions as we would anything else in the public API.
(I concur with the proposed primary/replica terminology)
In short:
* -1 to changing "Master" terminology in bugfix branches (unnecessary, too
invasive, disruptive to existing users, problems with
serialization/compatibility/classpath/packaging expectations)
* +0 to changing "Master" terminology in future versions, provided we can agree
on a more descriptive term (I'd prefer a separate ticket)
* +1 to Primary/Replica terminology (should be a sub-task of ACCUMULO-378)
* +1 to changing "slaves" to "tservers", provided we retain backwards
compatibility
* +1 to changing "slaves" to something else for the scalability tests and
elsewhere to whatever is most appropriate for that context
> Remove master/slave terminology
> -------------------------------
>
> Key: ACCUMULO-2844
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2844
> Project: Accumulo
> Issue Type: Task
> Affects Versions: 1.5.0, 1.5.1, 1.6.0
> Reporter: Sean Busbey
> Assignee: Sean Busbey
> Fix For: 1.5.2, 1.6.1, 1.7.0
>
>
> I'd like to remove our use of master/slave terminology in favor of something
> that doesn't carry a racially charged meaning.
> As a side effect I'd also like to pick names that carry better meaning of how
> things work within Accumulo.
> In the case of a single cluster, I'd like to
> * Change the Master role to Coordinator
> * Change the associated master server package to coordinator
> * Change the master configuration file to be named coordinators
> * Change the slaves configuration file to be named tservers
> In the case of the in-progress replication work I'd like to change
> terminology:
> * use _Primary Cluster_ in place of _Master Cluster_
> * use _Replica Clusters_ in place of _Slave Clusters_
> I intend to do this in all active branches in a way that maintains
> compatibility of existing configuration files and serialized actions (i.e.
> fate operations) within their major branch. In the current unreleased major
> branch I expect upgrading will require user action (e.g. renaming
> configuration files).
--
This message was sent by Atlassian JIRA
(v6.2#6252)