[
https://issues.apache.org/jira/browse/AMQ-7514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17377864#comment-17377864
]
Étienne Hossack edited comment on AMQ-7514 at 7/9/21, 7:06 AM:
---------------------------------------------------------------
Regarding your concerns [~michael.andre.pearce] for ActiveMQ 5.17+ as those are
the ones currently in question, since leveldb has been removed, I don't think
we have to worry about that confusion! Yes it could change in the future, but
the discussion is for right now, and we can't really predict the future it's a
good path forward in my opinion.
For Artemis I hear your concerns about states and designations. So rather than
introduce something new, maybe keeping the current live/backup as is used in
the docs is best? The config can reference Active/Replica or whichever as
needed to determine the intent of the node. I'll reiterate that "primary" or
"leader" are moderately confusing in the context of multiple HA pairs within an
Artemis cluster. I don't believe any of the terms in the linked article are any
clearer.
Your sentence "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" can be written as:
"When an Active node fails the Replica takes over [accepting traffic]. If you
have configured your broker with the 'allow-failback' option, when the original
Active is restarted, the Replica will resume replication and the Active node
will accept traffic."
I believe the confusion in your sentence comes from the capitalization and
referencing "failback" as concept before defining what that actually means in
the context of this HA pair.
In general I believe a broker user/documentation reader does not need to be
aware of a formal state in this context, and the implicit meaning in a sentence
can suffice (serving traffic).
edit: It might even reduce the cognitive load, since it's one less concept to
have to learn.
was (Author: ehossack):
Regarding your concerns [~michael.andre.pearce] for ActiveMQ 5.17+ as those are
the ones currently in question, since leveldb has been removed, I don't think
we have to worry about that confusion! Yes it could change in the future, but
the discussion is for right now, and we can't really predict the future it's a
good path forward in my opinion.
For Artemis I hear your concerns about states and designations. So rather than
introduce something new, maybe keeping the current live/backup as is used in
the docs is best? The config can reference Active/Replica or whichever as
needed to determine the intent of the node. I'll reiterate that "primary" or
"leader" are moderately confusing in the context of multiple HA pairs within an
Artemis cluster. I don't believe any of the terms in the linked article are any
clearer.
Your sentence "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" can be written as:
"When an Active node fails the Replica takes over [accepting traffic]. If you
have configured your broker with the 'allow-failback' option, when the original
Active is restarted, the Replica will resume replication and the Active node
will accept traffic."
I believe the confusion in your sentence comes from the capitalization and
referencing "failback" as concept before defining what that actually means in
the context of this HA pair.
In general I believe a broker user/documentation reader does not need to be
aware of a formal state in this context, and the implicit meaning in a sentence
can suffice (serving traffic).
> 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)
