[
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:25 AM:
--------------------------------------------------------------------
I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram]
For one second ignoring Artemis and just talking about Active MQ5 Classic, we
actually had addtional terms 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 passiveSlave in the. broker service where the Slave is still not
activated.
Regarding Replication in Artemis again, we have states, this is determined
master or slave, which you actively define the node type in the configuration,
with either the node becoming "Active", we even have the concepts of failback
to master for predominate master setups.
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]
was (Author: michael.andre.pearce):
I disagree [~ehossack] and [~mattrpav]. And fully agree with [~jbertram]
We actually had addtional terms 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 passiveSlave in the. broker service where the Slave is still not
activated.
Regarding Replication in Artemis again, we have states, this is determined
master or slave, which you actively define the node type in the configuration,
with either the node becoming "Active", we even have the concepts of failback
to master for predominate master setups.
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]
> 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)
