[ https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17377801#comment-17377801 ]
Étienne Hossack edited comment on AMQ-7514 at 7/9/21, 4:47 AM: --------------------------------------------------------------- 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." _becomes_ "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 was (Author: ehossack): 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)