You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Matt Pavlovich <ma...@gmail.com> on 2021/07/12 17:40:42 UTC

[PROPOSAL] Non-canonical alignment for shared and replicated state terminology 

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

[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

Re: [PROPOSAL] Non-canonical alignment for shared and replicated state terminology

Posted by JB Onofré <jb...@nanthrax.net>.
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 <eh...@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: ehossack@amazon.com
> 
> 
> 
>>> On Jul 16, 2021, at 1:06 PM, Matt Pavlovich <ma...@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 <eh...@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: ehossack@amazon.com <ma...@amazon.com>
>>> 
>>> 
>>> 
>>>> On Jul 12, 2021, at 10:40 AM, Matt Pavlovich <mattrpav@gmail.com <ma...@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
>>>> 
>>> 
>> 
>

Re: [PROPOSAL] Non-canonical alignment for shared and replicated state terminology

Posted by "Hossack, Etienne" <eh...@amazon.com.INVALID>.
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: ehossack@amazon.com<ma...@amazon.com>

[cid:0CFB4B72-BC66-42A8-953C-779D7FAE3DC0@amazon.com]

On Jul 16, 2021, at 1:06 PM, Matt Pavlovich <ma...@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 <eh...@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: ehossack@amazon.com<ma...@amazon.com> <ma...@amazon.com>



On Jul 12, 2021, at 10:40 AM, Matt Pavlovich <ma...@gmail.com> <ma...@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

Re: [PROPOSAL] Non-canonical alignment for shared and replicated state terminology

Posted by Matt Pavlovich <ma...@gmail.com>.
Hi Étienne-

> On Jul 16, 2021, at 12:46 PM, Hossack, Etienne <eh...@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: ehossack@amazon.com <ma...@amazon.com>
> 
> 
> 
>> On Jul 12, 2021, at 10:40 AM, Matt Pavlovich <mattrpav@gmail.com <ma...@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
>> 
>

Re: [PROPOSAL] Non-canonical alignment for shared and replicated state terminology

Posted by "Hossack, Etienne" <eh...@amazon.com.INVALID>.
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"
  *   The broker layer knows best what state it is in by using information from the persistence layer and can expose “active” and “standby”
  *   In the case of shared storage, “mode” is meaningless, so this is omitted
  *   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).


Étienne Hossack
Software Development Engineer, Amazon MQ
email: ehossack@amazon.com<ma...@amazon.com>

[cid:0CFB4B72-BC66-42A8-953C-779D7FAE3DC0@amazon.com]

On Jul 12, 2021, at 10:40 AM, Matt Pavlovich <ma...@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>
   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>

[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

Re: [PROPOSAL] Non-canonical alignment for shared and replicated state terminology

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Matt,

thanks for the proposal.

Personally, I'm still skeptical about this kind of changes for 
"technical wording".

If we really want to change, I think active/passive is the most accurate 
for kahadb/store HA, both runtime mode and status. Anyway, in ActiveMQ, 
we don't have concrete wording in the configuration (it's more in the code).

So, +1 with the proposal, +0 for change (I see more drawback than benefit).

Regards
JB

On 7/12/21 7:40 PM, Matt Pavlovich wrote:
> [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>
>      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>
> 
> [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
> 
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com