You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by Cameron McKenzie <mc...@gmail.com> on 2014/10/24 07:03:40 UTC

Re: ZooKeeper 3.5.0 is coming

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 <jordan@jordanzimmerman.com
> 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 <ma...@cloudera.com> <ma...@cloudera.com>
> Reply: dev@curator.apache.org <de...@curator.apache.org>>
> <de...@curator.apache.org>
> Date: August 7, 2014 at 10:28:16 AM
> To: dev@curator.apache.org <de...@curator.apache.org>>
> <de...@curator.apache.org>
> Cc: Cameron McKenzie <mc...@gmail.com>> <mc...@gmail.com>
> 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 <
> jordan@jordanzimmerman.com
> > 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 <mc...@gmail.com>
> > Reply: dev@curator.apache.org <de...@curator.apache.org>>
> > Date: August 7, 2014 at 12:45:21 AM
> > To: dev@curator.apache.org <de...@curator.apache.org>>
> > 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
> >
>
>

Re: ZooKeeper 3.5.0 is coming

Posted by Cameron McKenzie <mc...@gmail.com>.
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 <ma...@cloudera.com> 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 <
> jordan@jordanzimmerman.com> 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 (madrob@cloudera.com)
>> 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 <
>> jordan@jordanzimmerman.com> 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 (
>>> mckenzie.cam@gmail.com) 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 <
>>> jordan@jordanzimmerman.com> 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 <ma...@cloudera.com> <ma...@cloudera.com>
>>>> Reply: dev@curator.apache.org <de...@curator.apache.org>>
>>>> <de...@curator.apache.org>
>>>> Date: August 7, 2014 at 10:28:16 AM
>>>> To: dev@curator.apache.org <de...@curator.apache.org>>
>>>> <de...@curator.apache.org>
>>>> Cc: Cameron McKenzie <mc...@gmail.com>> <mc...@gmail.com>
>>>> 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 <
>>>> jordan@jordanzimmerman.com
>>>> > 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 <mc...@gmail.com>
>>>> > Reply: dev@curator.apache.org <de...@curator.apache.org>>
>>>> > Date: August 7, 2014 at 12:45:21 AM
>>>> > To: dev@curator.apache.org <de...@curator.apache.org>>
>>>> > 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
>>>> >
>>>>
>>>>
>>>
>>
>

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I’ll take a look later and get back to you. I took a cursory look and it seems right. I too was wondering whether Curator should auto-start the watcher or not. I need to think about that some more. Maybe other committers have an idea as well.


On November 10, 2014 at 11:46:03 AM, Ioannis Canellos (iocanel@gmail.com) wrote:

Any thoughts on what I posted about the EnsemblerProvider / EnsembleTracker?  

On Mon, Nov 10, 2014 at 5:55 PM, Jordan Zimmerman  
<jo...@jordanzimmerman.com> wrote:  
> So, it would get added to the Retry logic as another retry-able excetpion?  
> I’ll ask on the ZK list to make sure.  
>  
>  
> On November 10, 2014 at 6:35:07 AM, Ioannis Canellos (iocanel@gmail.com)  
> wrote:  
>  
> From what I understand its not an indication of invalid config, its  
> rather an indication that things are not ready for the operation, as  
> it just indicates that the quorum of servers that are meant to be part  
> of the "new" ensemble are not yet synced with the leader (which is a  
> requirement).  
>  
> The description on the code explicitly tells that we should try again  
> when all servers are connected and synced, so it definitely sounds  
> like a retry-able one.  
>  
>  
> On Fri, Nov 7, 2014 at 8:04 PM, Jordan Zimmerman  
> <jo...@jordanzimmerman.com> wrote:  
>> In the ZooKeeper meetup yesterday, Alex mentioned the exception  
>> NewConfigNoQuorum. I was a bit unclear on this. Is this thrown when the  
>> new  
>> config is invalid or is it a new kind of recoverable exception? If it’s  
>> recoverable, Curator will need to handle it I guess.  
>>  
>> -JZ  
>>  
>>  
>> On November 6, 2014 at 11:07:41 AM, Jordan Zimmerman  
>> (jordan@jordanzimmerman.com) wrote:  
>>  
>> Please create PRs for these so that we can review.  
>>  
>> Thanks for the great start.  
>>  
>> -Jordan  
>>  
>>  
>> On November 6, 2014 at 10:45:53 AM, Ioannis Canellos (iocanel@gmail.com)  
>> wrote:  
>>  
>> The branch CURATOR-3.0 has been created. If we agree that we want to  
>> rename it to 3.x we can do that.  
>>  
>> I also created and pushed a first draft of CURATOR-160. The commit  
>> adds builders and DSL on the CuratorFramework for the new config() and  
>> reconfig() methods of ZooKeeper. It also contains a unit test that  
>> tries out possible combinations.  
>>  
>> As a next step, I think that we should extend the existing DSL (which  
>> heavily uses strings following the ZooKeepers methods signatures) and  
>> provide methods with more meaningful signatures. If you lost me, here  
>> is an example of how it can be used.  
>>  
>>  
>> client.reconfig().join("server.4=someip:2888:3888;participant;2181").join("server.5=someotherip:2888:3888;participant;2181).forConfig(someVersion);  
>>  
>> It's somehow painful to remember the format of the string, so I think  
>> that we should provide an alternative for join that could look like:  
>>  
>> join(long id, String host, int clientPort, int peerPort, int  
>> electionPort, String type);  
>>  
>> Meanwhile I'll start looking at implementing an EnsembleProvider that  
>> will be reconfiguration aware, which is required to close the issue.  
>>  
>>  
>>  
>> On Thu, Nov 6, 2014 at 11:48 AM, Ioannis Canellos <io...@gmail.com>  
>> wrote:  
>>> Agreed, though I would name the common branch 3.x (mostly to separate  
>>> it from the issue branches).  
>>>  
>>>  
>>> On Wed, Nov 5, 2014 at 5:54 PM, Jordan Zimmerman  
>>> <jo...@jordanzimmerman.com> wrote:  
>>>> Also, I think we should still make separate branches for each feature  
>>>> but  
>>>> have a CURATOR-3.0 branch for managing the completed features.  
>>>>  
>>>> -JZ  
>>>>  
>>>>  
>>>> On November 5, 2014 at 9:52:16 AM, Ioannis Canellos (iocanel@gmail.com)  
>>>> wrote:  
>>>>  
>>>> So I picked up CURATOR-160 from the list.  
>>>>  
>>>> What I have in mind is creating a 3.x branch (as I think that we  
>>>> generally agree on this) and then add the required DSL on the curator  
>>>> framework to support the reconfig and getconfig methods.  
>>>>  
>>>> As a next step we need to decide how we will handle internally the  
>>>> reconfiguration of zookeeper. Personally I like the idea of an  
>>>> EnsembleProvider implementation.  
>>>>  
>>>> Thoughts?  
>>>>  
>>>> On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman  
>>>> <jo...@jordanzimmerman.com> wrote:  
>>>>> FYI  
>>>>>  
>>>>> I’ve created a container Jira for ZK 3.5.0 subtasks:  
>>>>>  
>>>>> https://issues.apache.org/jira/browse/CURATOR-159  
>>>>>  
>>>>>  
>>>>> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman  
>>>>> (jordan@jordanzimmerman.com) wrote:  
>>>>>  
>>>>> I think we should identify the tasks, create Jiras, etc. Then figure  
>>>>> out  
>>>>> the  
>>>>> best path from there. So, in that spirit, let’s begin.  
>>>>>  
>>>>> Major new features in 3.5.x that Curator needs to handle in some way:  
>>>>>  
>>>>> * Dynamic Reconfig  
>>>>> * Remove Watches  
>>>>> * Local Session  
>>>>>  
>>>>> Here is the current 3.5.x release notes page. Is there anything else  
>>>>> from  
>>>>> here that Curator should handle?  
>>>>>  
>>>>>  
>>>>>  
>>>>>  
>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644  
>>>>>  
>>>>> -Jordan  
>>>>>  
>>>>>  
>>>>> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos  
>>>>> (iocanel@gmail.com)  
>>>>> wrote:  
>>>>>  
>>>>> Is anyone working on this? I could spend some time on zk 3.5.0.  
>>>>>  
>>>>> --  
>>>>> Ioannis Canellos  
>>>>>  
>>>>> Blog: http://iocanel.blogspot.com  
>>>>> Twitter: iocanel  
>>>>  
>>>>  
>>>>  
>>>> --  
>>>> Ioannis Canellos  
>>>>  
>>>> Blog: http://iocanel.blogspot.com  
>>>> Twitter: iocanel  
>>>  
>>>  
>>>  
>>> --  
>>> Ioannis Canellos  
>>>  
>>> Blog: http://iocanel.blogspot.com  
>>> Twitter: iocanel  
>>  
>>  
>>  
>> --  
>> Ioannis Canellos  
>>  
>> Blog: http://iocanel.blogspot.com  
>> Twitter: iocanel  
>  
>  
>  
> --  
> Ioannis Canellos  
>  
> Blog: http://iocanel.blogspot.com  
> Twitter: iocanel  



--  
Ioannis Canellos  

Blog: http://iocanel.blogspot.com  
Twitter: iocanel  

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
So, it would get added to the Retry logic as another retry-able excetpion? I’ll ask on the ZK list to make sure.


On November 10, 2014 at 6:35:07 AM, Ioannis Canellos (iocanel@gmail.com) wrote:

From what I understand its not an indication of invalid config, its  
rather an indication that things are not ready for the operation, as  
it just indicates that the quorum of servers that are meant to be part  
of the "new" ensemble are not yet synced with the leader (which is a  
requirement).  

The description on the code explicitly tells that we should try again  
when all servers are connected and synced, so it definitely sounds  
like a retry-able one.  


On Fri, Nov 7, 2014 at 8:04 PM, Jordan Zimmerman  
<jo...@jordanzimmerman.com> wrote:  
> In the ZooKeeper meetup yesterday, Alex mentioned the exception  
> NewConfigNoQuorum. I was a bit unclear on this. Is this thrown when the new  
> config is invalid or is it a new kind of recoverable exception? If it’s  
> recoverable, Curator will need to handle it I guess.  
>  
> -JZ  
>  
>  
> On November 6, 2014 at 11:07:41 AM, Jordan Zimmerman  
> (jordan@jordanzimmerman.com) wrote:  
>  
> Please create PRs for these so that we can review.  
>  
> Thanks for the great start.  
>  
> -Jordan  
>  
>  
> On November 6, 2014 at 10:45:53 AM, Ioannis Canellos (iocanel@gmail.com)  
> wrote:  
>  
> The branch CURATOR-3.0 has been created. If we agree that we want to  
> rename it to 3.x we can do that.  
>  
> I also created and pushed a first draft of CURATOR-160. The commit  
> adds builders and DSL on the CuratorFramework for the new config() and  
> reconfig() methods of ZooKeeper. It also contains a unit test that  
> tries out possible combinations.  
>  
> As a next step, I think that we should extend the existing DSL (which  
> heavily uses strings following the ZooKeepers methods signatures) and  
> provide methods with more meaningful signatures. If you lost me, here  
> is an example of how it can be used.  
>  
> client.reconfig().join("server.4=someip:2888:3888;participant;2181").join("server.5=someotherip:2888:3888;participant;2181).forConfig(someVersion);  
>  
> It's somehow painful to remember the format of the string, so I think  
> that we should provide an alternative for join that could look like:  
>  
> join(long id, String host, int clientPort, int peerPort, int  
> electionPort, String type);  
>  
> Meanwhile I'll start looking at implementing an EnsembleProvider that  
> will be reconfiguration aware, which is required to close the issue.  
>  
>  
>  
> On Thu, Nov 6, 2014 at 11:48 AM, Ioannis Canellos <io...@gmail.com> wrote:  
>> Agreed, though I would name the common branch 3.x (mostly to separate  
>> it from the issue branches).  
>>  
>>  
>> On Wed, Nov 5, 2014 at 5:54 PM, Jordan Zimmerman  
>> <jo...@jordanzimmerman.com> wrote:  
>>> Also, I think we should still make separate branches for each feature but  
>>> have a CURATOR-3.0 branch for managing the completed features.  
>>>  
>>> -JZ  
>>>  
>>>  
>>> On November 5, 2014 at 9:52:16 AM, Ioannis Canellos (iocanel@gmail.com)  
>>> wrote:  
>>>  
>>> So I picked up CURATOR-160 from the list.  
>>>  
>>> What I have in mind is creating a 3.x branch (as I think that we  
>>> generally agree on this) and then add the required DSL on the curator  
>>> framework to support the reconfig and getconfig methods.  
>>>  
>>> As a next step we need to decide how we will handle internally the  
>>> reconfiguration of zookeeper. Personally I like the idea of an  
>>> EnsembleProvider implementation.  
>>>  
>>> Thoughts?  
>>>  
>>> On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman  
>>> <jo...@jordanzimmerman.com> wrote:  
>>>> FYI  
>>>>  
>>>> I’ve created a container Jira for ZK 3.5.0 subtasks:  
>>>>  
>>>> https://issues.apache.org/jira/browse/CURATOR-159  
>>>>  
>>>>  
>>>> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman  
>>>> (jordan@jordanzimmerman.com) wrote:  
>>>>  
>>>> I think we should identify the tasks, create Jiras, etc. Then figure out  
>>>> the  
>>>> best path from there. So, in that spirit, let’s begin.  
>>>>  
>>>> Major new features in 3.5.x that Curator needs to handle in some way:  
>>>>  
>>>> * Dynamic Reconfig  
>>>> * Remove Watches  
>>>> * Local Session  
>>>>  
>>>> Here is the current 3.5.x release notes page. Is there anything else  
>>>> from  
>>>> here that Curator should handle?  
>>>>  
>>>>  
>>>>  
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644  
>>>>  
>>>> -Jordan  
>>>>  
>>>>  
>>>> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com)  
>>>> wrote:  
>>>>  
>>>> Is anyone working on this? I could spend some time on zk 3.5.0.  
>>>>  
>>>> --  
>>>> Ioannis Canellos  
>>>>  
>>>> Blog: http://iocanel.blogspot.com  
>>>> Twitter: iocanel  
>>>  
>>>  
>>>  
>>> --  
>>> Ioannis Canellos  
>>>  
>>> Blog: http://iocanel.blogspot.com  
>>> Twitter: iocanel  
>>  
>>  
>>  
>> --  
>> Ioannis Canellos  
>>  
>> Blog: http://iocanel.blogspot.com  
>> Twitter: iocanel  
>  
>  
>  
> --  
> Ioannis Canellos  
>  
> Blog: http://iocanel.blogspot.com  
> Twitter: iocanel  



--  
Ioannis Canellos  

Blog: http://iocanel.blogspot.com  
Twitter: iocanel  

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
In the ZooKeeper meetup yesterday, Alex mentioned the exception NewConfigNoQuorum. I was a bit unclear on this. Is this thrown when the new config is invalid or is it a new kind of recoverable exception? If it’s recoverable, Curator will need to handle it I guess.

-JZ


On November 6, 2014 at 11:07:41 AM, Jordan Zimmerman (jordan@jordanzimmerman.com) wrote:

Please create PRs for these so that we can review.

Thanks for the great start.

-Jordan


On November 6, 2014 at 10:45:53 AM, Ioannis Canellos (iocanel@gmail.com) wrote:

The branch CURATOR-3.0 has been created. If we agree that we want to
rename it to 3.x we can do that.

I also created and pushed a first draft of CURATOR-160. The commit
adds builders and DSL on the CuratorFramework for the new config() and
reconfig() methods of ZooKeeper. It also contains a unit test that
tries out possible combinations.

As a next step, I think that we should extend the existing DSL (which
heavily uses strings following the ZooKeepers methods signatures) and
provide methods with more meaningful signatures. If you lost me, here
is an example of how it can be used.

client.reconfig().join("server.4=someip:2888:3888;participant;2181").join("server.5=someotherip:2888:3888;participant;2181).forConfig(someVersion);

It's somehow painful to remember the format of the string, so I think
that we should provide an alternative for join that could look like:

join(long id, String host, int clientPort, int peerPort, int
electionPort, String type);

Meanwhile I'll start looking at implementing an EnsembleProvider that
will be reconfiguration aware, which is required to close the issue.



On Thu, Nov 6, 2014 at 11:48 AM, Ioannis Canellos <io...@gmail.com> wrote:
> Agreed, though I would name the common branch 3.x (mostly to separate
> it from the issue branches).
>
>
> On Wed, Nov 5, 2014 at 5:54 PM, Jordan Zimmerman
> <jo...@jordanzimmerman.com> wrote:
>> Also, I think we should still make separate branches for each feature but
>> have a CURATOR-3.0 branch for managing the completed features.
>>
>> -JZ
>>
>>
>> On November 5, 2014 at 9:52:16 AM, Ioannis Canellos (iocanel@gmail.com)
>> wrote:
>>
>> So I picked up CURATOR-160 from the list.
>>
>> What I have in mind is creating a 3.x branch (as I think that we
>> generally agree on this) and then add the required DSL on the curator
>> framework to support the reconfig and getconfig methods.
>>
>> As a next step we need to decide how we will handle internally the
>> reconfiguration of zookeeper. Personally I like the idea of an
>> EnsembleProvider implementation.
>>
>> Thoughts?
>>
>> On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman
>> <jo...@jordanzimmerman.com> wrote:
>>> FYI
>>>
>>> I’ve created a container Jira for ZK 3.5.0 subtasks:
>>>
>>> https://issues.apache.org/jira/browse/CURATOR-159
>>>
>>>
>>> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman
>>> (jordan@jordanzimmerman.com) wrote:
>>>
>>> I think we should identify the tasks, create Jiras, etc. Then figure out
>>> the
>>> best path from there. So, in that spirit, let’s begin.
>>>
>>> Major new features in 3.5.x that Curator needs to handle in some way:
>>>
>>> * Dynamic Reconfig
>>> * Remove Watches
>>> * Local Session
>>>
>>> Here is the current 3.5.x release notes page. Is there anything else from
>>> here that Curator should handle?
>>>
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644
>>>
>>> -Jordan
>>>
>>>
>>> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com)
>>> wrote:
>>>
>>> Is anyone working on this? I could spend some time on zk 3.5.0.
>>>
>>> --
>>> Ioannis Canellos
>>>
>>> Blog: http://iocanel.blogspot.com
>>> Twitter: iocanel
>>
>>
>>
>> --
>> Ioannis Canellos
>>
>> Blog: http://iocanel.blogspot.com
>> Twitter: iocanel
>
>
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel



--
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Please create PRs for these so that we can review.

Thanks for the great start.

-Jordan


On November 6, 2014 at 10:45:53 AM, Ioannis Canellos (iocanel@gmail.com) wrote:

The branch CURATOR-3.0 has been created. If we agree that we want to  
rename it to 3.x we can do that.  

I also created and pushed a first draft of CURATOR-160. The commit  
adds builders and DSL on the CuratorFramework for the new config() and  
reconfig() methods of ZooKeeper. It also contains a unit test that  
tries out possible combinations.  

As a next step, I think that we should extend the existing DSL (which  
heavily uses strings following the ZooKeepers methods signatures) and  
provide methods with more meaningful signatures. If you lost me, here  
is an example of how it can be used.  

client.reconfig().join("server.4=someip:2888:3888;participant;2181").join("server.5=someotherip:2888:3888;participant;2181).forConfig(someVersion);  

It's somehow painful to remember the format of the string, so I think  
that we should provide an alternative for join that could look like:  

join(long id, String host, int clientPort, int peerPort, int  
electionPort, String type);  

Meanwhile I'll start looking at implementing an EnsembleProvider that  
will be reconfiguration aware, which is required to close the issue.  



On Thu, Nov 6, 2014 at 11:48 AM, Ioannis Canellos <io...@gmail.com> wrote:  
> Agreed, though I would name the common branch 3.x (mostly to separate  
> it from the issue branches).  
>  
>  
> On Wed, Nov 5, 2014 at 5:54 PM, Jordan Zimmerman  
> <jo...@jordanzimmerman.com> wrote:  
>> Also, I think we should still make separate branches for each feature but  
>> have a CURATOR-3.0 branch for managing the completed features.  
>>  
>> -JZ  
>>  
>>  
>> On November 5, 2014 at 9:52:16 AM, Ioannis Canellos (iocanel@gmail.com)  
>> wrote:  
>>  
>> So I picked up CURATOR-160 from the list.  
>>  
>> What I have in mind is creating a 3.x branch (as I think that we  
>> generally agree on this) and then add the required DSL on the curator  
>> framework to support the reconfig and getconfig methods.  
>>  
>> As a next step we need to decide how we will handle internally the  
>> reconfiguration of zookeeper. Personally I like the idea of an  
>> EnsembleProvider implementation.  
>>  
>> Thoughts?  
>>  
>> On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman  
>> <jo...@jordanzimmerman.com> wrote:  
>>> FYI  
>>>  
>>> I’ve created a container Jira for ZK 3.5.0 subtasks:  
>>>  
>>> https://issues.apache.org/jira/browse/CURATOR-159  
>>>  
>>>  
>>> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman  
>>> (jordan@jordanzimmerman.com) wrote:  
>>>  
>>> I think we should identify the tasks, create Jiras, etc. Then figure out  
>>> the  
>>> best path from there. So, in that spirit, let’s begin.  
>>>  
>>> Major new features in 3.5.x that Curator needs to handle in some way:  
>>>  
>>> * Dynamic Reconfig  
>>> * Remove Watches  
>>> * Local Session  
>>>  
>>> Here is the current 3.5.x release notes page. Is there anything else from  
>>> here that Curator should handle?  
>>>  
>>>  
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644  
>>>  
>>> -Jordan  
>>>  
>>>  
>>> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com)  
>>> wrote:  
>>>  
>>> Is anyone working on this? I could spend some time on zk 3.5.0.  
>>>  
>>> --  
>>> Ioannis Canellos  
>>>  
>>> Blog: http://iocanel.blogspot.com  
>>> Twitter: iocanel  
>>  
>>  
>>  
>> --  
>> Ioannis Canellos  
>>  
>> Blog: http://iocanel.blogspot.com  
>> Twitter: iocanel  
>  
>  
>  
> --  
> Ioannis Canellos  
>  
> Blog: http://iocanel.blogspot.com  
> Twitter: iocanel  



--  
Ioannis Canellos  

Blog: http://iocanel.blogspot.com  
Twitter: iocanel  

Re: ZooKeeper 3.5.0 is coming

Posted by Ioannis Canellos <io...@gmail.com>.
The branch CURATOR-3.0 has been created. If we agree that we want to
rename it to 3.x we can do that.

I also created and pushed a first draft of CURATOR-160. The commit
adds builders and DSL on the CuratorFramework for the new config() and
reconfig() methods of ZooKeeper. It also contains a unit test that
tries out possible combinations.

As a next step, I think that we should extend the existing DSL (which
heavily uses strings following the ZooKeepers methods signatures) and
provide methods with more meaningful signatures. If you lost me, here
is an example of how it can be used.

client.reconfig().join("server.4=someip:2888:3888;participant;2181").join("server.5=someotherip:2888:3888;participant;2181).forConfig(someVersion);

It's somehow painful to remember the format of the string, so I think
that we should provide an alternative for join that could look like:

join(long id, String host, int clientPort, int peerPort, int
electionPort, String type);

Meanwhile I'll start looking at implementing an EnsembleProvider that
will be reconfiguration aware, which is required to close the issue.



On Thu, Nov 6, 2014 at 11:48 AM, Ioannis Canellos <io...@gmail.com> wrote:
> Agreed, though I would name the common branch 3.x (mostly to separate
> it from the issue branches).
>
>
> On Wed, Nov 5, 2014 at 5:54 PM, Jordan Zimmerman
> <jo...@jordanzimmerman.com> wrote:
>> Also, I think we should still make separate branches for each feature but
>> have a CURATOR-3.0 branch for managing the completed features.
>>
>> -JZ
>>
>>
>> On November 5, 2014 at 9:52:16 AM, Ioannis Canellos (iocanel@gmail.com)
>> wrote:
>>
>> So I picked up CURATOR-160 from the list.
>>
>> What I have in mind is creating a 3.x branch (as I think that we
>> generally agree on this) and then add the required DSL on the curator
>> framework to support the reconfig and getconfig methods.
>>
>> As a next step we need to decide how we will handle internally the
>> reconfiguration of zookeeper. Personally I like the idea of an
>> EnsembleProvider implementation.
>>
>> Thoughts?
>>
>> On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman
>> <jo...@jordanzimmerman.com> wrote:
>>> FYI
>>>
>>> I’ve created a container Jira for ZK 3.5.0 subtasks:
>>>
>>> https://issues.apache.org/jira/browse/CURATOR-159
>>>
>>>
>>> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman
>>> (jordan@jordanzimmerman.com) wrote:
>>>
>>> I think we should identify the tasks, create Jiras, etc. Then figure out
>>> the
>>> best path from there. So, in that spirit, let’s begin.
>>>
>>> Major new features in 3.5.x that Curator needs to handle in some way:
>>>
>>> * Dynamic Reconfig
>>> * Remove Watches
>>> * Local Session
>>>
>>> Here is the current 3.5.x release notes page. Is there anything else from
>>> here that Curator should handle?
>>>
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644
>>>
>>> -Jordan
>>>
>>>
>>> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com)
>>> wrote:
>>>
>>> Is anyone working on this? I could spend some time on zk 3.5.0.
>>>
>>> --
>>> Ioannis Canellos
>>>
>>> Blog: http://iocanel.blogspot.com
>>> Twitter: iocanel
>>
>>
>>
>> --
>> Ioannis Canellos
>>
>> Blog: http://iocanel.blogspot.com
>> Twitter: iocanel
>
>
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel



-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: ZooKeeper 3.5.0 is coming

Posted by Ioannis Canellos <io...@gmail.com>.
Agreed, though I would name the common branch 3.x (mostly to separate
it from the issue branches).


On Wed, Nov 5, 2014 at 5:54 PM, Jordan Zimmerman
<jo...@jordanzimmerman.com> wrote:
> Also, I think we should still make separate branches for each feature but
> have a CURATOR-3.0 branch for managing the completed features.
>
> -JZ
>
>
> On November 5, 2014 at 9:52:16 AM, Ioannis Canellos (iocanel@gmail.com)
> wrote:
>
> So I picked up CURATOR-160 from the list.
>
> What I have in mind is creating a 3.x branch (as I think that we
> generally agree on this) and then add the required DSL on the curator
> framework to support the reconfig and getconfig methods.
>
> As a next step we need to decide how we will handle internally the
> reconfiguration of zookeeper. Personally I like the idea of an
> EnsembleProvider implementation.
>
> Thoughts?
>
> On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman
> <jo...@jordanzimmerman.com> wrote:
>> FYI
>>
>> I’ve created a container Jira for ZK 3.5.0 subtasks:
>>
>> https://issues.apache.org/jira/browse/CURATOR-159
>>
>>
>> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman
>> (jordan@jordanzimmerman.com) wrote:
>>
>> I think we should identify the tasks, create Jiras, etc. Then figure out
>> the
>> best path from there. So, in that spirit, let’s begin.
>>
>> Major new features in 3.5.x that Curator needs to handle in some way:
>>
>> * Dynamic Reconfig
>> * Remove Watches
>> * Local Session
>>
>> Here is the current 3.5.x release notes page. Is there anything else from
>> here that Curator should handle?
>>
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644
>>
>> -Jordan
>>
>>
>> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com)
>> wrote:
>>
>> Is anyone working on this? I could spend some time on zk 3.5.0.
>>
>> --
>> Ioannis Canellos
>>
>> Blog: http://iocanel.blogspot.com
>> Twitter: iocanel
>
>
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel



-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Also, I think we should still make separate branches for each feature but have a CURATOR-3.0 branch for managing the completed features.

-JZ


On November 5, 2014 at 9:52:16 AM, Ioannis Canellos (iocanel@gmail.com) wrote:

So I picked up CURATOR-160 from the list.  

What I have in mind is creating a 3.x branch (as I think that we  
generally agree on this) and then add the required DSL on the curator  
framework to support the reconfig and getconfig methods.  

As a next step we need to decide how we will handle internally the  
reconfiguration of zookeeper. Personally I like the idea of an  
EnsembleProvider implementation.  

Thoughts?  

On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman  
<jo...@jordanzimmerman.com> wrote:  
> FYI  
>  
> I’ve created a container Jira for ZK 3.5.0 subtasks:  
>  
> https://issues.apache.org/jira/browse/CURATOR-159  
>  
>  
> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman  
> (jordan@jordanzimmerman.com) wrote:  
>  
> I think we should identify the tasks, create Jiras, etc. Then figure out the  
> best path from there. So, in that spirit, let’s begin.  
>  
> Major new features in 3.5.x that Curator needs to handle in some way:  
>  
> * Dynamic Reconfig  
> * Remove Watches  
> * Local Session  
>  
> Here is the current 3.5.x release notes page. Is there anything else from  
> here that Curator should handle?  
>  
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644  
>  
> -Jordan  
>  
>  
> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com)  
> wrote:  
>  
> Is anyone working on this? I could spend some time on zk 3.5.0.  
>  
> --  
> Ioannis Canellos  
>  
> Blog: http://iocanel.blogspot.com  
> Twitter: iocanel  



--  
Ioannis Canellos  

Blog: http://iocanel.blogspot.com  
Twitter: iocanel  

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
EnsembleProvider has always been my preference.


On November 5, 2014 at 9:52:16 AM, Ioannis Canellos (iocanel@gmail.com) wrote:

So I picked up CURATOR-160 from the list.  

What I have in mind is creating a 3.x branch (as I think that we  
generally agree on this) and then add the required DSL on the curator  
framework to support the reconfig and getconfig methods.  

As a next step we need to decide how we will handle internally the  
reconfiguration of zookeeper. Personally I like the idea of an  
EnsembleProvider implementation.  

Thoughts?  

On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman  
<jo...@jordanzimmerman.com> wrote:  
> FYI  
>  
> I’ve created a container Jira for ZK 3.5.0 subtasks:  
>  
> https://issues.apache.org/jira/browse/CURATOR-159  
>  
>  
> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman  
> (jordan@jordanzimmerman.com) wrote:  
>  
> I think we should identify the tasks, create Jiras, etc. Then figure out the  
> best path from there. So, in that spirit, let’s begin.  
>  
> Major new features in 3.5.x that Curator needs to handle in some way:  
>  
> * Dynamic Reconfig  
> * Remove Watches  
> * Local Session  
>  
> Here is the current 3.5.x release notes page. Is there anything else from  
> here that Curator should handle?  
>  
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644  
>  
> -Jordan  
>  
>  
> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com)  
> wrote:  
>  
> Is anyone working on this? I could spend some time on zk 3.5.0.  
>  
> --  
> Ioannis Canellos  
>  
> Blog: http://iocanel.blogspot.com  
> Twitter: iocanel  



--  
Ioannis Canellos  

Blog: http://iocanel.blogspot.com  
Twitter: iocanel  

Re: ZooKeeper 3.5.0 is coming

Posted by Ioannis Canellos <io...@gmail.com>.
So I picked up CURATOR-160 from the list.

What I have in mind is creating a 3.x branch (as I think that we
generally agree on this) and then add the required DSL on the curator
framework to support the reconfig and getconfig methods.

As a next step we need to decide how we will handle internally the
reconfiguration of zookeeper. Personally I like the idea of an
EnsembleProvider implementation.

Thoughts?

On Sat, Nov 1, 2014 at 6:29 PM, Jordan Zimmerman
<jo...@jordanzimmerman.com> wrote:
> FYI
>
> I’ve created a container Jira for ZK 3.5.0 subtasks:
>
> https://issues.apache.org/jira/browse/CURATOR-159
>
>
> On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman
> (jordan@jordanzimmerman.com) wrote:
>
> I think we should identify the tasks, create Jiras, etc. Then figure out the
> best path from there. So, in that spirit, let’s begin.
>
> Major new features in 3.5.x that Curator needs to handle in some way:
>
> * Dynamic Reconfig
> * Remove Watches
> * Local Session
>
> Here is the current 3.5.x release notes page. Is there anything else from
> here that Curator should handle?
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644
>
> -Jordan
>
>
> On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com)
> wrote:
>
> Is anyone working on this? I could spend some time on zk 3.5.0.
>
> --
> Ioannis Canellos
>
> Blog: http://iocanel.blogspot.com
> Twitter: iocanel



-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
FYI

I’ve created a container Jira for ZK 3.5.0 subtasks: 

https://issues.apache.org/jira/browse/CURATOR-159


On November 1, 2014 at 11:25:35 AM, Jordan Zimmerman (jordan@jordanzimmerman.com) wrote:

I think we should identify the tasks, create Jiras, etc. Then figure out the best path from there. So, in that spirit, let’s begin.

Major new features in 3.5.x that Curator needs to handle in some way:

* Dynamic Reconfig
* Remove Watches
* Local Session

Here is the current 3.5.x release notes page. Is there anything else from here that Curator should handle?

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644

-Jordan


On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com) wrote:

Is anyone working on this? I could spend some time on zk 3.5.0.

--
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I think we should identify the tasks, create Jiras, etc. Then figure out the best path from there. So, in that spirit, let’s begin.

Major new features in 3.5.x that Curator needs to handle in some way:

* Dynamic Reconfig
* Remove Watches
* Local Session

Here is the current 3.5.x release notes page. Is there anything else from here that Curator should handle?

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644

-Jordan


On November 1, 2014 at 11:21:35 AM, Ioannis Canellos (iocanel@gmail.com) wrote:

Is anyone working on this? I could spend some time on zk 3.5.0.  

--  
Ioannis Canellos  

Blog: http://iocanel.blogspot.com  
Twitter: iocanel  

Re: ZooKeeper 3.5.0 is coming

Posted by Ioannis Canellos <io...@gmail.com>.
Is anyone working on this? I could spend some time on zk 3.5.0.

-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: ZooKeeper 3.5.0 is coming

Posted by Ioannis Canellos <io...@gmail.com>.
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
<jo...@jordanzimmerman.com> wrote:
> +1
>
>
> On October 24, 2014 at 12:04:11 PM, Mike Drob (madrob@cloudera.com) 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 <jo...@jordanzimmerman.com> 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 (madrob@cloudera.com) 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 <jo...@jordanzimmerman.com> 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 (mckenzie.cam@gmail.com) 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 <jo...@jordanzimmerman.com> 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 <ma...@cloudera.com>
> Reply: dev@curator.apache.org <de...@curator.apache.org>>
> Date: August 7, 2014 at 10:28:16 AM
> To: dev@curator.apache.org <de...@curator.apache.org>>
> Cc: Cameron McKenzie <mc...@gmail.com>>
> 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 <jordan@jordanzimmerman.com
>> 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 <mc...@gmail.com>
>> Reply: dev@curator.apache.org <de...@curator.apache.org>>
>> Date: August 7, 2014 at 12:45:21 AM
>> To: dev@curator.apache.org <de...@curator.apache.org>>
>> 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

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
+1


On October 24, 2014 at 12:04:11 PM, Mike Drob (madrob@cloudera.com) 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 <jo...@jordanzimmerman.com> 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 (madrob@cloudera.com) 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 <jo...@jordanzimmerman.com> 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 (mckenzie.cam@gmail.com) 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 <jo...@jordanzimmerman.com> 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 <ma...@cloudera.com>
Reply: dev@curator.apache.org <de...@curator.apache.org>>
Date: August 7, 2014 at 10:28:16 AM
To: dev@curator.apache.org <de...@curator.apache.org>>
Cc: Cameron McKenzie <mc...@gmail.com>>
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 <jordan@jordanzimmerman.com
> 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 <mc...@gmail.com>
> Reply: dev@curator.apache.org <de...@curator.apache.org>>
> Date: August 7, 2014 at 12:45:21 AM
> To: dev@curator.apache.org <de...@curator.apache.org>>
> 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
>




Re: ZooKeeper 3.5.0 is coming

Posted by Mike Drob <ma...@cloudera.com>.
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 <
jordan@jordanzimmerman.com> 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 (madrob@cloudera.com) 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 <
> jordan@jordanzimmerman.com> 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 (
>> mckenzie.cam@gmail.com) 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 <
>> jordan@jordanzimmerman.com> 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 <ma...@cloudera.com> <ma...@cloudera.com>
>>> Reply: dev@curator.apache.org <de...@curator.apache.org>>
>>> <de...@curator.apache.org>
>>> Date: August 7, 2014 at 10:28:16 AM
>>> To: dev@curator.apache.org <de...@curator.apache.org>>
>>> <de...@curator.apache.org>
>>> Cc: Cameron McKenzie <mc...@gmail.com>> <mc...@gmail.com>
>>> 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 <
>>> jordan@jordanzimmerman.com
>>> > 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 <mc...@gmail.com>
>>> > Reply: dev@curator.apache.org <de...@curator.apache.org>>
>>> > Date: August 7, 2014 at 12:45:21 AM
>>> > To: dev@curator.apache.org <de...@curator.apache.org>>
>>> > 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
>>> >
>>>
>>>
>>
>

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 (madrob@cloudera.com) 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 <jo...@jordanzimmerman.com> 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 (mckenzie.cam@gmail.com) 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 <jo...@jordanzimmerman.com> 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 <ma...@cloudera.com>
Reply: dev@curator.apache.org <de...@curator.apache.org>>
Date: August 7, 2014 at 10:28:16 AM
To: dev@curator.apache.org <de...@curator.apache.org>>
Cc: Cameron McKenzie <mc...@gmail.com>>
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 <jordan@jordanzimmerman.com
> 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 <mc...@gmail.com>
> Reply: dev@curator.apache.org <de...@curator.apache.org>>
> Date: August 7, 2014 at 12:45:21 AM
> To: dev@curator.apache.org <de...@curator.apache.org>>
> 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
>



Re: ZooKeeper 3.5.0 is coming

Posted by Mike Drob <ma...@cloudera.com>.
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 <
jordan@jordanzimmerman.com> 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 (
> mckenzie.cam@gmail.com) 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 <
> jordan@jordanzimmerman.com> 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 <ma...@cloudera.com> <ma...@cloudera.com>
>> Reply: dev@curator.apache.org <de...@curator.apache.org>>
>> <de...@curator.apache.org>
>> Date: August 7, 2014 at 10:28:16 AM
>> To: dev@curator.apache.org <de...@curator.apache.org>>
>> <de...@curator.apache.org>
>> Cc: Cameron McKenzie <mc...@gmail.com>> <mc...@gmail.com>
>> 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 <
>> jordan@jordanzimmerman.com
>> > 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 <mc...@gmail.com>
>> > Reply: dev@curator.apache.org <de...@curator.apache.org>>
>> > Date: August 7, 2014 at 12:45:21 AM
>> > To: dev@curator.apache.org <de...@curator.apache.org>>
>> > 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
>> >
>>
>>
>

Re: ZooKeeper 3.5.0 is coming

Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
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 (mckenzie.cam@gmail.com) 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 <jo...@jordanzimmerman.com> 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 <ma...@cloudera.com>
Reply: dev@curator.apache.org <de...@curator.apache.org>>
Date: August 7, 2014 at 10:28:16 AM
To: dev@curator.apache.org <de...@curator.apache.org>>
Cc: Cameron McKenzie <mc...@gmail.com>>
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 <jordan@jordanzimmerman.com
> 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 <mc...@gmail.com>
> Reply: dev@curator.apache.org <de...@curator.apache.org>>
> Date: August 7, 2014 at 12:45:21 AM
> To: dev@curator.apache.org <de...@curator.apache.org>>
> 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
>