When a user pulls up a web page or dashboard with a field next to the broker name what should they see?
Use Case 1: Why would it makes sense to a user that has a 5-broker NOB cluster see the term ‘primary’ 5 times? Use Case 2: Why would a user that has a single broker see a status of ‘primary’? Use Case 3: With two ‘master’ and two 'slave’ brokers in a cluster the user would see ‘primary’, ‘backup’, ‘primary’, ‘backup’. What does that mean? How can I have two ‘primary’ brokers? What are the ‘backup’ instances backing up? See how these terms makes no sense in the context of how ActiveMQ brokers work and how users use them? All these use cases make more sense with: +1 Active / Standby I think the terminology is really important here, since there is already interest (redis) for adding add’l data store backends and enhancements to kahadb (replication)— and to have a goal to align with Artemis. -1 Leader/Follower — this should be reserved for a state or status flag at the persistence layer -1 Backup — this is a bad term for using with a systems that store data. IMO in incorrectly insinuates that there is data being ‘backed-up’, which is not the case with ActiveMQ 5.x. -1 Primary — this is not a great term, since there is no secondary or tertiary concept. This also insinuates that there are always multiple instances. ActiveMQ 5.x only has a state — active or polling to become active. Transport connectors, network connectors, etc all go offline. These primary/leader/follower concepts should be pushed down to the persistence layer. Thanks, Matt Pavlovich > On May 6, 2022, at 1:26 AM, Tetreault, Lucas <tetlu...@amazon.com.INVALID> > wrote: > > Hey folks, > > I don’t know if I’m actually allowed to call for a vote given I’m not a > committer/PMC member but Michael André Pearce made it clear on Slack that > this was the only way to move this discussion forward and come to a final > conclusion on the issue so here goes nothing. If I’m not supposed to call for > a vote, perhaps someone could “sponsor” this request :) > > > A tweet [1] from a few days ago raised the issue of non-inclusive terminology > in the AWS docs related to ActiveMQ [2] and suggested that we should replace > “masterslave” with a more inclusive name for the network connector transport. > Replacing master/slave nomenclature in ActiveMQ was raised as a Jira issue in > July 2020 [3] and again on the mailing list in November 2020 [7]. There was > some initial work to rename the git branch from master to main, 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) and Matt Pavlovich drafted a > thorough proposal on the mailing list [6], 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. > > > > From all the previous discussions, I believe we have two options to replace > master/slave. Artemis will need to layer on a status (e.g.: active/standby) > but I think we can move forward on this vote without deciding what those > terms should be assuming people agree these options will support having a > status layered on top. > > > > Please submit your +1/-1 vote on the following terms and please provide > specific comments/alternatives if you’re -1 for both options. > > [ ] Leader/Follower > > [ ] Primary/Backup > > > > > > [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/ > [6] https://lists.apache.org/thread/rcwogpchjo9p461hqoj6m89q9t2qpqjj > [7] https://lists.apache.org/thread/5ntnrbz1l92xbvno0s2jxhhf7nbs8d9c > > Lucas Tétreault > Software Development Manager, Amazon MQ > email: tetlu...@amazon.com<mailto:tetlu...@amazon.com> > >
