[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17377842#comment-17377842
]
Michael Andre Pearce edited comment on AMQ-7514 at 7/9/21, 6:53 AM:
--------------------------------------------------------------------
I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram]
For one second ignoring Artemis and just talking about MQ5 Classic, we actually
had additional terms/use for master and slave when we had leveldb with its
"pure master slave" and like wise back with replicated kaha db, the broker
service master and slave actually was around the nodes role, and then it became
active when it took over. To this point we actually still have the slave in
what we call a "Passive Slave" in the broker service where the Slave is still
not activated.
Regarding Replication in Artemis again, we have node states and node
designations, the node designations being master or slave, which you actively
define the node type in the configuration, with either having the possibility
to becoming "Active" which means the node currently servicing, we even have the
concepts of failback to master for predominate master setups. The Slave never
becomes master and a master never becomes a slave, they keep their
designations, their state simply changes to becoming "Active"
For this reason i think we really need to avoid the words "Active" or "Slave"
for defining a node, we use it to mean the current state of a node, if we start
overloading the term as you suggest.... we will end up with phrases like "When
an Active node fails the Replica takes over, and becomes and Active Replica but
if you have fail back to Active configured when the Active node is restarted
the Active Replica will failback to the Active node and it will become Active
Active again" Like seriously WTF...... its a terminology disaster.
There is plenty of alternatives to the words Master/Slave that avoid the word
"Active" so lets simply avoid the problem......
[https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now]
I personally like Leader / Standby or Leader / Follower, but im for any
alternative (Primary / Replica) thats NOT simply using the words Active/Passive
for a nodes designation, its the nodes state, which we have historically used
the word active and passive, to define and describe the nodes current state,
especially in artemis and prior in classic with leveldb and replicated kahadb
previously.
Leader and Standby/Follower has no connotation that you only have one master
like you do with the word primary, e.g. like in network of brokers(classic) or
in clustering (artemis) where you can have multi masters. And like wise
Standby/Follower has no connotation you can only have 1 like with the word
secondary, also it avoids the confusion where not using replication defining a
slave as replica, when not actually network replication based master slave
setup.
Why make a terminology problem, if we don't have to.....
was (Author: michael.andre.pearce):
I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram]
For one second ignoring Artemis and just talking about MQ5 Classic, we actually
had additional terms/use for master and slave when we had leveldb with its
"pure master slave" and like wise back with replicated kaha db, the broker
service master and slave actually was around the nodes role, and then it became
active when it took over. To this point we actually still have the slave in
what we call a "Passive Slave" in the broker service where the Slave is still
not activated.
Regarding Replication in Artemis again, we have node states and node
designations, the node designations being master or slave, which you actively
define the node type in the configuration, with either having the possibility
to becoming "Active" which means the node currently servicing, we even have the
concepts of failback to master for predominate master setups. The Slave never
becomes master and a master never becomes a slave, they keep their
designations, their state simply changes to becoming "Active"
For this reason i think we really need to avoid the words "Active" or "Slave"
for defining a node, we use it to mean the current state of a node, if we start
overloading the term as you suggest.... we will end up with phrases like "When
an Active node fails the Replica takes over, but if you have fail back to
Active configured when the Active node is restarted the Active Replica will
failback to the Active node and it will become Active again" Like seriously
WTF...... its a terminology disaster.
There is plenty of alternatives to the words Master/Slave that avoid the word
"Active" so lets simply avoid the problem......
[https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now]
I personally like Leader / Standby or Leader / Follower, but im for any
alternative (Primary / Replica) thats NOT simply using the words Active/Passive
for a nodes designation, its the nodes state, which we have historically used
the word active and passive, to define and describe the nodes current state,
especially in artemis and prior in classic with leveldb and replicated kahadb
previously.
Leader and Standby/Follower has no connotation that you only have one master
like you do with the word primary, e.g. like in network of brokers(classic) or
in clustering (artemis) where you can have multi masters. And like wise
Standby/Follower has no connotation you can only have 1 like with the word
secondary, also it avoids the confusion where not using replication defining a
slave as replica, when not actually network replication based master slave
setup.
Why make a terminology problem, if we don't have to.....
> Replace racially charged terms throughout source code, comments and
> documentation
> ---------------------------------------------------------------------------------
>
> Key: AMQ-7514
> URL: https://issues.apache.org/jira/browse/AMQ-7514
> Project: ActiveMQ
> Issue Type: Task
> Reporter: Bruce Snyder
> Priority: Major
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> Given the racial charged nature of certain terms in today's world, we must
> pull together to create a plan for changing any such terms throughout all the
> ActiveMQ projects and in the git repos themselves.
>
> Example: [https://activemq.apache.org/masterslave.html]
>
> Here are just a few terms that should be changed: * The following terms are
> being targeted for change:
> *
> ** 'master' and 'slave' should be replaced with the terms 'live' and 'backup'
> ** 'whitelist' and 'blacklist' should be replaced with the terms 'allowlist'
> and 'denylist'
> * Rename all the git 'master' branches to the term 'main'
> Proposal notes from activemq-dev mailing list
> Phase 1:
> 1. Deprecate terms such as ‘master’ and ’slave
> 2. log.warn any configuration change notifications
> 3. Provide compatibility under the covers for deprecated terms
> 4. Provide any openwire compatibility changes b/w ActiveMQ 5 and Artemis
> 5. Notify users in an announcement and provide a conversion HOWTO
> Phase 2:
> 1. Remove terminology as part of a major or minor release (SEMVER where ‘y’
> in ‘x.y.z’ is minor version number)
> New terms:
> a. For shared storage: ‘active’ and ’standby’
> b. For replication: ‘primary’ and ‘replica'
> c. For 'white list' and 'blacklist': 'allow list' and 'deny list'
> For example:
> ‘master’ -> ‘active’
> ’slave’ -> ’standby'
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
