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>
> > >
> > >
> >
> >
>

Reply via email to