Re: Re: [DISCUSSION] New Quorum vote pluggable implementation

[nigro_franz <ni...@gmail.com>]

Thanks for all the feedbacks: I see this is an hot topic for sure :)

In the next week I will start putting some idea in a shared doc and open a
discussion on slack to collect some ideas & soft/hard requirements in order
to decide a roadmap: ATM I'm very conflicted how much we should leverage on
some of the mechanisms what we currently have (Activation(s), Topology
propagation etc etc) abstracting it away into a more generic API or just
designing a new thing from scratch and then trying to make the current
behaviour to fit into it to help migration or to let existing users to not
be forced to adopt the new one until it wil meet their needs.

Regardless which direction to take one of my "best to have" is the
convergence between shared-store and replication ha into a sigle solution
with 2 "flavours": for what HA has been done until now is just matter of
keep integrity and the right ownership of the journal (considering the fact
that with Ceph/GlusterFS the sync replication is provided at file-system
level and with the current "software replication" is up to the broker to
perform it).
It looks to me that things like FileLockNodeManager or the JdbcNodeManager
are just 2 possible building blocks to provide the functionality that allow
to detect a loss in the journal ownership and could be used as building
blocks to implement (the shared store flavour of) the new API to manage the
live-backup(s) states.

Just thinking loud; another thing that could be a nice thing to have
(looking at kafka at this, although they allow it with a finer granularity)
is the multiple-backups synchronization to increase availability of the
service: if anyone has specific concern or any idea why it shouldn't be a
good idea, feel free to share it.

Happy easter and enjoy the longer week-end



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html

Re: Re: [DISCUSSION] New Quorum vote pluggable implementation

["michael.andre.pearce" <mi...@me.com.INVALID>]

I would be against us bringing in something that makes a nasty barrier for entry for existing users.Think about the current situation with classic and artemis where one of the biggest issues has been that a user cannot simply take his/her configuration and just update the broker to the new version, theres quite some minefield to migrate. And probably alot of the reason why still a large part of community is still on classic.If we ended up coming up with some system that starts from scratch and makes it that maybe not all is implemented we will basically be making that chasm worse.We should be making this as easy as possible for existing users / admins to just upgrade. User Community needs to come first here.Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: nigro_franz <ni...@gmail.com> Date: 11/04/2020  18:42  (GMT+00:00) To: dev@activemq.apache.org Subject: Re: Re: [DISCUSSION] New Quorum vote pluggable implementation Thanks for all the feedbacks: I see this is an hot topic for sure :)In the next week I will start putting some idea in a shared doc and open adiscussion on slack to collect some ideas & soft/hard requirements in orderto decide a roadmap: ATM I'm very conflicted how much we should leverage onsome of the mechanisms what we currently have (Activation(s), Topologypropagation etc etc) abstracting it away into a more generic API or justdesigning a new thing from scratch and then trying to make the currentbehaviour to fit into it to help migration or to let existing users to notbe forced to adopt the new one until it wil meet their needs.Regardless which direction to take one of my "best to have" is theconvergence between shared-store and replication ha into a sigle solutionwith 2 "flavours": for what HA has been done until now is just matter ofkeep integrity and the right ownership of the journal (considering the factthat with Ceph/GlusterFS the sync replication is provided at file-systemlevel and with the current "software replication" is up to the broker toperform it).It looks to me that things like FileLockNodeManager or the JdbcNodeManagerare just 2 possible building blocks to provide the functionality that allowto detect a loss in the journal ownership and could be used as buildingblocks to implement (the shared store flavour of) the new API to manage thelive-backup(s) states.Just thinking loud; another thing that could be a nice thing to have(looking at kafka at this, although they allow it with a finer granularity)is the multiple-backups synchronization to increase availability of theservice: if anyone has specific concern or any idea why it shouldn't be agood idea, feel free to share it.Happy easter and enjoy the longer week-end--Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html