Hey folks,
I wanted to provide an update on this work. After lots of discussion on GitHub
and Slack it has become apparent that I unnecessarily coupled the work to
remove non-inclusive terms from the "masterslave" discovery transport to the
use of non-inclusive terms in general within ActiveMQ.
I have updated my original PR to use "staticfailover" instead of "masterslave"
for the discovery protocol, as recommended by Robbie Gemmell, which succinctly
describes the purpose of the discovery protocol and isn't tied to any
particular topology or naming convention.
I will follow up shortly with a proposal and vote regarding nomenclature to
replace the non-inclusive master/slave.
Thanks,
Lucas
Software Development Manager, Amazon MQ
email: tetlu...@amazon.com
On 2022-04-29, 1:41 PM, "Matt Pavlovich" <mattr...@gmail.com> wrote:
CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you can confirm the sender and know the
content is safe.
Hey Lucas,
I think this is a good time to start working in these changes as work
starts on 5.18.0.
My thoughts:
Pav-1. This is a widely used url, we should take care to transition users.
I suggest add this new handler and deprecate masterslave.
Pav-2. IMHO 'leaderfollower’ is incorrect terminology— in this use case, it
really is just a ‘failover’ behavior and there is no relation to the
architecture of the target broker(s).
Thanks,
Matt Pavlovich
> On Apr 29, 2022, at 1:08 PM, Tetreault, Lucas
<tetlu...@amazon.com.INVALID> wrote:
>
> Hey folks,
>
> TLDR;
> I am submitting a PR to rename the "masterslave" network connector
transport to "leaderfollower" and I propose that we use leader/follower going
forward to replace all references to master/slave.
>
> The Long Version:
> A tweet from a few days ago [1] raised the issue of non-inclusive
terminology in the AWS docs [2] and suggested that we should replace
masterslave with a more inclusive name for the network connector transport. The
AWS docs refer to a feature of ActiveMQ that is a convenience discovery agent:
https://activemq.apache.org/networks-of-brokers#masterslave-discovery. We are
planning to change the docs to remove the recommendation to use the masterslave
transport.
>
> Replacing master/slave nomenclature in ActiveMQ was raised in July 2020
[3]. There was some initial work to rename the git branch from master to main
and there have been some attempts at making some changes to the code
(https://github.com/apache/activemq/pull/679,
https://github.com/apache/activemq/pull/714,
https://github.com/apache/activemq/pull/788) however we have not been able to
come to an agreement on nomenclature so these efforts seem to have stalled out.
>
> If we are able to come to an agreement on nomenclature, we can move
forward with removing more non-inclusive terminology on the website (I will
follow up with some PRs to the website), in discussions with the community and
of course in the codebase. This will remove barriers to adoption and make
ActiveMQ a more approachable and inclusive project for everyone! Other Apache
projects such as Solr and Kafka have moved from master/slave to
leader/follower. Leader/follower is also recommended by the IETF [4] and
inclusivenaming.org [5] which is supported by companies such as Cisco, Intel,
and RedHat. At AWS, we have used active/standby to describe HA deployments,
however from previous discussions it's clear that active/standby is not a
viable option for this community since 'active' can be used to describe so many
things. If we can agree on leader/follower or some alternate we would follow
the community's preference and adopt leader/follower to better serve our
ActiveMQ users.
>
> If we can't come to an agreement on Leader/Follower or some other
nomenclature I will, at the very least, create a follow up PR to remove the
masterslave transport since it is just a convenience method to use
static+failover with ?randomize=false&maxReconnectAttempts=0.
>
> [1] https://twitter.com/owenblacker/status/1517156221207212032
> [2]
https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/amazon-mq-creating-configuring-network-of-brokers.html#creating-configuring-network-of-brokers-configure-network-connectors
> [3] https://issues.apache.org/jira/browse/AMQ-7514
> [4] https://tools.ietf.org/id/draft-knodel-terminology-02.html
> [5] https://inclusivenaming.org/word-lists/tier-1/
>
> Thanks,
>
> Lucas Tétreault
> Software Development Manager, Amazon MQ
> email: tetlu...@amazon.com
>
