I like the idea of supporting zookeeper's 3.5.0 features in curator 3.x, mostly because doing that as part of 2.x would slow down the release cycles of 2.x.
I also like the idea of implementing an ensemble provider that will start with a configured zookeeper url and then watch for dynamic reconfiguration changes and update the internal connection string. It is a chicken and egg problem as Cameron said, but then again the loop is not introduced by curator, its introduced by zookeeper itself, so we can't do much here. If we follow the "mindset" used by zookeeper itself, we could also persist in a file or something the updated connection string, so that upon restarts we can reuse the latest known connection string. On Sun, Oct 26, 2014 at 6:59 AM, Jordan Zimmerman <[email protected]> wrote: > +1 > > > On October 24, 2014 at 12:04:11 PM, Mike Drob ([email protected]) wrote: > > That's fine too. Probably something like Curator 2.7.X is the last one to > support ZK 3.4.X and then Curator 2.8.0 will have ZK 3.5 features? We can > leave the possibility of a 2.7.1 in the future in case there turns out to be > some particularly relevant bug that needs to be addressed. > > On Fri, Oct 24, 2014 at 1:00 PM, Jordan Zimmerman > <[email protected]> wrote: > When 3.4.5 came out with the transaction APIs I just documented that version > X.X.X (I forget which) was the last version of Curator that would support > 3.3.x and below. We could do the same for this. > > -JZ > > > On October 24, 2014 at 11:58:48 AM, Mike Drob ([email protected]) wrote: > > I would strongly prefer to have one version, even if it means that we need to > do some reflection hacking under the hood. I think it greatly simplifies the > narrative for users both when starting out and when upgrading. > > On Fri, Oct 24, 2014 at 11:50 AM, Jordan Zimmerman > <[email protected]> wrote: > I haven’t had time. The upcoming ZooKeeper meetup should give details on when > to expect 3.5.0. One thing we might need to do is have two versions of > Curator for a while as not everyone will move to 3.5.0 immediately. > > -Jordan > > > On October 24, 2014 at 12:03:41 AM, Cameron McKenzie ([email protected]) > wrote: > > Has anyone had any further thoughts about ZK 3.5 and dynamic cluster > reconfiguration? > > I had a look into the EnsembleProvider interface, but I don't think that it > will work because it is used to create the connection to ZooKeeper, and from > my (limited) understanding of the way that cluster configuration works in ZK > 3.5, you need a connection to ZK before you can work out all of the nodes in > the cluster. So, there is a bit of a chicken and egg problem. > > cheers > Cam > > On Fri, Aug 8, 2014 at 2:20 AM, Jordan Zimmerman <[email protected]> > wrote: > We could use a label. However, I have version 3.0.0 set for ZK 3.5.x > compatibility so we can just use that. > > -JZ > > > From: Mike Drob <[email protected]> > Reply: [email protected] <[email protected]>> > Date: August 7, 2014 at 10:28:16 AM > To: [email protected] <[email protected]>> > Cc: Cameron McKenzie <[email protected]>> > Subject: Re: ZooKeeper 3.5.0 is coming > > I saw that they added the ability to remove watches, so that could be a > viable approach for CURATOR-14? > > Are we using a JIRA label to group the issues and make them easily findable? > > Mike > > > On Thu, Aug 7, 2014 at 9:54 AM, Jordan Zimmerman <[email protected] >> wrote: > >> I think we should list all the changes that we need to do and get Jira’s >> written for them (targeted for version 3.0.0) and then we can divide up the >> work. >> >> -JZ >> >> >> From: Cameron McKenzie <[email protected]> >> Reply: [email protected] <[email protected]>> >> Date: August 7, 2014 at 12:45:21 AM >> To: [email protected] <[email protected]>> >> Subject: Re: ZooKeeper 3.5.0 is coming >> >> I'm happy to start looking into this in a bit more detail unless someone >> else has their heart set on it. >> cheers >> Cam >> > > > -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
