[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17377801#comment-17377801
]
Étienne Hossack commented on AMQ-7514:
--------------------------------------
I am mostly in agreement with [~mattrpav] here, but I don't think it's
unreasonable to consider the problem holistically. Let's outline the state of
the world:
ActiveMQ
* Single Node
* 2 nodes one actively serving traffic, one waiting to grab the lock
* Network of brokers
Artemis
* Single node
* 2 nodes configured with an HA policy of shared storage, one waiting to grab
the lock
* A cluster wherein nodes are configured to actively serve traffic, or with an
HA policy of replica, continuously replicating a node that is serving traffic
* A node which is configured to mirror another node
* A federation of nodes
Within this context, I think we can rule out NoB and federation as each of
these connected nodes could also coincide with any of the other HA policies.
In the context of a single node, the instance is just actively servicing
traffic so we could refrain from terminology or just call it active.
In the context of shared storage at any given point one node is actively
serving requests, and another is standing by waiting to serve them. Both
Active/Passive and Active/Standby could describe this. However I would argue
that the alternatives "follower", "secondary", "backup", and "replica" are not
applicable because this pairing has (reasons respective to the alternatives
ordering): no context that it is not a leader, no awareness of another node, no
knowledge it's a backup, and is not replicating state. I personally think
standby is a better fit because, as one would imagine say a soldier or a
firefighter, the second node is constantly checking the lock and waiting to
start serving traffic rather than passively waiting to be told it must start.
In the context of a node within a cluster, with a replicated HA policy, since
the one node is continuously replicating traffic, I would think the clearest
terminology would be a "replica". The alternatives, "secondary" might be
confusing in a cluster with say 6 nodes, 3 of which are active. Follower/backup
could be used, but I personally think that follower is better paired with
leader (still confusing in a 6 node cluster) and although backup still might
apply, but since there's established terminology of HA policy replica.
In the context of a mirror, given that its specific purpose is in disaster
recovery rather than immediate recovery via replication, I would think that
either backup, or recovery would apply. Although this has no configuration the
docs could be adjusted.
For all of the above Artemis states, I think that Active continues to best
describe a node that is currently serving traffic, assuming the intent here is
to align terminology across the two engines (an alternative to this would of
course be to continue using "live" in Artemis, but promote that to a top-level
concept in config). I think adding in an extra term to describe the combined
state (e.g. active replica) only adds confusion. One can simply say the
"now-active replica node", or "current active node". Even the docs say things
like, "In case of "shared disk", simply restart the original live server and
kill the new live server. You can do this by killing the process itself." ->
"In case of "shared disk", simply restart the original -live- active server,
and -kill- stop the new -live- active server. You can do this by -killing-
stopping the process itself"
So to summarize, what I'd propose:
ActiveMQ
* Active/Standby
Artemis
* Active/Standby via shared storage
* Active/Replica via network replication
* Active/Recovery via AMQP mirror
> 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)
