Sorry if I’m being naive. I am trying to understand why your brought the configuration and upgrade topic.
Is that a subject you are bringing now or you already see a problem ? Quórum implementation is orthogonal to the config I think. We have been keeping any confirmation options compatible With previous versions so far. On Sat, Apr 11, 2020 at 4:39 PM Michael Pearce <michaelpea...@apache.org> wrote: > (Try again using my other mail account so formatting of my mail doesnt muck > up) > > > 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. > > On Mon, 2 Mar 2020, 08:28 nigro_franz, <nigro....@gmail.com> wrote: > > > Hi folks, > > > > especially due to the requirements of the current Artemis quorum vote > > algorithm, we've thought to re-implementing it with a different focus in > > mind: > > 1) to make it pluggable (eg by using the many Raft implementations, > > ZooKeeper or others) > > 2) to cleanly separate the election phase and cluster member states (ie > it > > should be the Topology shared between them) > > 3) to simplify most common setups in both amount of configuration and > > requirements (eg "witness" nodes could be implemented to get a minimum > 2*n > > +1 quorum of nodes instead of forcing 2*n + 1 master-backup pairs) > > 4) [OPTIONALLY] to reduce/eliminate implicit "good practices" in term of > > order of actions to be performed on nodes in "special states" eg proper > > restart sequence after failover or similar cases > > 5) [OPTIONALLY] to make shared-store and replication behaviour more > > similar: > > journal's presence should be the only difference between the 2s > > > > A proposal of steps to be followed to get this: > > 1) abstract away the current quorum vote: it requires extra-care because > > the > > logic is melted together with the replication/clustering behaviour > > 2) refactor it in order to separate election phase and cluster member > > states > > 3) implement a RI version of such APIs > > > > Post-actions to help people adopt it, but need to be thought upfront: > > 1) a clean upgrade path for current HA replication users > > 2) deprecate or integrate the current HA replication into the new version > > > > I've opened this here because many of the HA replication users are devs > too > > and given that this isn't yet implemented: we're stull in the > > design/proposal phase, so anyone that want to express their > > ideas/opinions/POC on this, is invited to talk here ;) > > > > Cheers, > > Franz > > > > > > > > > > > > -- > > Sent from: > > http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html > > > -- Clebert Suconic
