Hi Etienne Thanks for the reminder. I will check to move forward, probably one 5.17 RC1 will be out.
Regards JB > Le 12 août 2021 à 22:25, Hossack, Etienne <ehoss...@amazon.com.invalid> a > écrit : > > Hey folks, reminder this proposal is still out there and could use some > love :) > > In case it was ambiguous from my last email: > > +1 in favour > > Étienne Hossack > Software Development Engineer, Amazon MQ > email: ehoss...@amazon.com > > > >>> On Jul 16, 2021, at 1:06 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. >>> >>> >>> >>> Hi Étienne- >>> >>> On Jul 16, 2021, at 12:46 PM, Hossack, Etienne >>> <ehoss...@amazon.com.INVALID> wrote: >>> >>> Thanks for the proposal Matt. >>> >>> I am in favour of the [Scope][Benefits][Rationale] sections of your >>> proposal. They are clear. >>> >>> I am pretty sure I’m in favour of the [Proposal] section, so assuming my >>> understanding is correct, and the voice of a humble community member is >>> helpful, it's +1 at least on my end :) >>> The persistence layer knows best what term to use for mode, so it can >>> expose words like, “primary”, “leader”, “follower” or “replica" >> >> Yes, that was the “ah-ha” moment for me at least. Assigning a canonical term >> to underlying replication tech terminology is fraught with challenges and >> users would be better served by bubbling up the terms and status “as-is” >> from the underlying replication technology. >> >>> The broker layer knows best what state it is in by using information from >>> the persistence layer and can expose “active” and “standby” >> >> Yep. >> >>> In the case of shared storage, “mode” is meaningless, so this is omitted >> >> Yep. >> >>> None of these have to be verbs, and likely won’t be? (I can’t think of any >>> reason why a verb offers any added clarity for the existing supported >>> options in the project). >> >> I carried this idea forward from @Justin Bertram’s suggestion (and @Michael >> André Pearce echo’d support) with a goal of building towards some consensus— >> it is not something that exists in ActiveMQ 5 today, but the Artemis is >> gearing for it, so the idea in this part of the Proposal is to align where >> it makes sense between the two for underway and future ActiveMQ-project >> created replication tech. >> >> Thanks, >> Matt Pavlovich >> >> >> >>> >>> >>> Étienne Hossack >>> Software Development Engineer, Amazon MQ >>> email: ehoss...@amazon.com <mailto:ehoss...@amazon.com> >>> >>> >>> >>>> On Jul 12, 2021, at 10:40 AM, Matt Pavlovich <mattr...@gmail.com >>>> <mailto: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. >>>> >>>> >>>> >>>> [Abstract] >>>> >>>> ActiveMQ 5 and Artemis are both re-working legacy terminology to better >>>> describe function and move away from problematic language for shared >>>> storage and replication terminology indicators. >>>> >>>> [Background] >>>> >>>> JIRA discussion: https://issues.apache.org/jira/browse/AMQ-7514 >>>> <https://issues.apache.org/jira/browse/AMQ-7514> >>>> <https://issues.apache.org/jira/browse/AMQ-7514 >>>> <https://issues.apache.org/jira/browse/AMQ-7514>> >>>> Mailing list: >>>> http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html >>>> >>>> <http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html> >>>> >>>> <http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html >>>> >>>> <http://activemq.2283324.n4.nabble.com/DISCUSS-Draft-proposal-for-terminology-change-td4758351.html>> >>>> >>>> [Proposal] >>>> >>>> P-1. Broker layer will maintain a status— ‘active’ or ’standby’ based on >>>> signals from persistence layer >>>> >>>> P-2. Persistence layer will optionally provide a noun and verb based on >>>> the underlying technology's terminology. >>>> >>>> P-3. ActiveMQ project created persistence layers that support >>>> replication, the terminology should attempt to provide noun and verb terms >>>> to describe the mode and state. >>>> Mode: ‘primary’ and ‘replica’ >>>> Status: ‘active’ and ’standby' >>>> >>>> [Scope] >>>> >>>> S-1. Terminology alignment between ActiveMQ 5 and Artemis is only for >>>> shared storage, replicated storage, broker status, and future terms. >>>> >>>> [Benefits] >>>> >>>> B-1. Terms for Broker state will be aligned between ActiveMQ 5 and >>>> Artemis free of problematic language. >>>> >>>> B-2. Terms for replication will bubble up “as-is” based on the >>>> underlying persistence layer technology. >>>> >>>> B-3. If both ActiveMQ 5 and Artemis use the same replication tech, then >>>> terms will be aligned. >>>> >>>> B-4. If one provides a persistence layer adapter that the other does not >>>> there is no phantom noun or verb present on the other broker that has no >>>> direct technical meaning >>>> >>>> [Rationale] >>>> >>>> R-1. Attempting to create common terms may leave one broker with a >>>> phantom term that has no meaning >>>> >>>> R-2. Attempting to create common terms is problematic when two supported >>>> persistence adapter layer technology use different terms (leader / >>>> follower, vs primary / replica). >>>> >>>> R-3. Renaming terminology that is not problematic for the sake of >>>> alignment (ie. acceptor vs transportConnector) unfairly creates burden on >>>> the existing user base. >>>> >>>> >>>> Thank you, >>>> -Matt Pavlovich >>>> >>> >> >
