I don't think that backwards compatibility should be a big issue in regards to dynamic cluster configuration. But now that I think about it, if we're using the ability to revoke watches, then that will certainly cause compatibility issues. Agreed that a Curator 3.0 (or 2.8 or whatever) is the way forward. cheers
On Sat, Oct 25, 2014 at 4:03 AM, 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]> <[email protected]> >>>> Reply: [email protected] <[email protected]>> >>>> <[email protected]> >>>> Date: August 7, 2014 at 10:28:16 AM >>>> To: [email protected] <[email protected]>> >>>> <[email protected]> >>>> Cc: Cameron McKenzie <[email protected]>> <[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 >>>> > >>>> >>>> >>> >> >
