I think configuration and implementation are orthogonal here. With the new thing it should be possible to have a single replication pair. And having a new feature to control extra managers.
It’s a new feature I think. But you made a valid point on the config. On Sat, Apr 11, 2020 at 5:56 PM Michael Pearce <michaelpea...@apache.org> wrote: > It was in reference to Franzs last mail > > > "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." > > > I think the migration should be seemless to current users. It should > support current behaviours. > > If we dont we cause the same issue there is in migrating from classic to > Artemis. Just now in upgrading artemis. > > On Sat, 11 Apr 2020, 22:35 Clebert Suconic, <clebert.suco...@gmail.com> > wrote: > > > 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 > > > -- Clebert Suconic
