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 >
