+1 Chris and Justin rationale. I agree with having an agreed upon set of noun and adjective pairs for the project that the brokers can adopt accordingly.
Regarding the url term usage in ActiveMQ 5.x— that instance of the terminology usage is being corrected in an open PR, and can safely be disregarded as a use case for this convo. Thanks, Matt Pavlovich > On May 6, 2022, at 10:33 AM, Christopher Shannon > <christopher.l.shan...@gmail.com> wrote: > > Justin, > > Looks like you sent your response right when I sent mine where I mentioned > I was leaning towards having different terms between brokers. > > You more accurately described the situation than I did. It's not so much a > difference between 5.x and Artemis but two different scenarios of runtime > vs configuration and I like your idea of having a set of nouns and > adjectives and do think it would help solve the issue. I also think > the terms you picked work well so I would be in favor of going with both > sets and having Primary/Backup and also Active/Passive depending on the > situation described. > > Chris > > On Fri, May 6, 2022 at 11:23 AM Justin Bertram <jbert...@apache.org> wrote: > >>> When a user pulls up a web page or dashboard with a field next to the >> broker name what should they see? >> >> It depends on which ActiveMQ broker they're using. >> >> In ActiveMQ "Classic" there is no configured state, as you note. There is >> only runtime state, and it makes sense for that to be something like >> "Active" or "Passive." >> >> However, in ActiveMQ Artemis there is both configured state and runtime >> state so it would make sense to see something like "Active Primary," >> "Active Backup," "Passive Backup," etc. >> >> This gets back to a suggestion I made on AMQ-7514 [1] almost a year ago now >> - we need 2 nouns to denote configured state and 2 adjectives to denote >> runtime state and we need to use those consistently across code & >> documentation for both brokers. >> >> It may turn out that ActiveMQ "Classic" ultimately only uses the adjectives >> and that's 100% fine. However, there is currently both documentation and >> URL configuration which refers to "master" and "slave" in some capacity. >> >> In short, it's not sufficient to have just nouns or just adjectives. We >> need *both* for the project as a whole. I think this disconnect is one of >> the main reasons why we haven't resolved this matter already. >> >> My vote is for... >> >> Nouns: >> [+1] Primary/Backup >> >> Adjectives: >> [+1] Active/Passive >> >> >> Justin >> >> [1] >> >> https://issues.apache.org/jira/browse/AMQ-7514?focusedCommentId=17377740&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17377740 >> >> On Fri, May 6, 2022 at 9:36 AM Matt Pavlovich <mattr...@gmail.com> wrote: >> >>> 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> >>>> >>>> >>> >>> >>
