My 2 cents... For AMQ 5: Active / Passive or Active / Standby makes sense for H/A. NOB it does not apply - each "node" (H/A pair in case every broker is running in H/A) has active/passive pairs. So yes, a NOB could have a bunch of brokers all in Active state if none of the nodes is running H/A. NOB is never H/A.
For Artemis, since there is a designated Primary broker (the Secondary broker cannot become active until after the Primary starts and is Active), then it seems two sets of terms apply. Active/Passive for the actual runtime state, and Primary/Secondary for the assigned role. Live/Backup feels like it mixes the two - Live feels like runtime state. Backup feels like assigned role. Art On Fri, May 6, 2022 at 8: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> > > > > > > > > > > > > > > > > >
