You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2014/08/06 14:53:45 UTC
ZooKeeper 3.5.0 is coming
An alpha of ZooKeeper 3.5.0 is being released. We should start thinking about how Curator should adjust to 3.5.x features, in particular https://issues.apache.org/jira/browse/ZOOKEEPER-107 (dynamic reconfig).
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644
-Jordan
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
>
Re: ZooKeeper 3.5.0 is coming
Posted by Cameron McKenzie <mc...@gmail.com>.
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>.
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 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 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>.
Curator already has the EnsembleProvider interface that I wrote to integrate with Exhibitor. We might be able to repurpose it for this.
-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
From the following:
https://docs.google.com/document/d/1AF8pIfQbN5cKxe0c4cQ4_DW6ZjBJqSkyANcTGUwkzjc/edit
It appears that from Curator's point of view, we need to be aware of config
changes (by watching the /zookeeper/config zNode), to determine when the
clusters configuration has changed. Then, if it has changed, determine
whether our client needs to connect to a different host in the cluster.
There are underlying API calls on the Zookeeper client that handle the
algorithms for reconnection, Curator would just need to identify when the
changes occur.
Presumably we'd add something to the CuratorFramework and
CuratorFrameworkFactory classes.
This sort of changes the way that client configuration works to a degree.
Instead of it being a static thing where you configure your list of ZK
nodes, and that's it, now you're kind of configuring a set (potentially a
subset of all ZK nodes in the cluster) of ZK nodes that will then allow you
to look up the full set of nodes in the cluster. I would think that this
needs to be optional, but I think that it would be useful functionality to
have Curator be able to configure itself against what the ZK cluster
considers the cluster members to be at startup, and then dynamically
reconfigure itself as this changes.
So, essentially, Curator would:
-Start
-Connect to one of its configured ZK nodes
-Read the /zookeeper/config configuration
-Reconfigure itself based on that configuration
-Watch for future config updates.
I'm happy to start looking into this in a bit more detail unless someone
else has their heart set on it.
cheers
Cam
On Wed, Aug 6, 2014 at 10:53 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> An alpha of ZooKeeper 3.5.0 is being released. We should start thinking
> about how Curator should adjust to 3.5.x features, in particular
> https://issues.apache.org/jira/browse/ZOOKEEPER-107 (dynamic reconfig).
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644
>
> -Jordan
Re: ZooKeeper 3.5.0 is coming
Posted by Cameron McKenzie <mc...@gmail.com>.
>From the following:
https://docs.google.com/document/d/1AF8pIfQbN5cKxe0c4cQ4_DW6ZjBJqSkyANcTGUwkzjc/edit
It appears that from Curator's point of view, we need to be aware of config
changes (by watching the /zookeeper/config zNode), to determine when the
clusters configuration has changed. Then, if it has changed, determine
whether our client needs to connect to a different host in the cluster.
There are underlying API calls on the Zookeeper client that handle the
algorithms for reconnection, Curator would just need to identify when the
changes occur.
Presumably we'd add something to the CuratorFramework and
CuratorFrameworkFactory classes.
This sort of changes the way that client configuration works to a degree.
Instead of it being a static thing where you configure your list of ZK
nodes, and that's it, now you're kind of configuring a set (potentially a
subset of all ZK nodes in the cluster) of ZK nodes that will then allow you
to look up the full set of nodes in the cluster. I would think that this
needs to be optional, but I think that it would be useful functionality to
have Curator be able to configure itself against what the ZK cluster
considers the cluster members to be at startup, and then dynamically
reconfigure itself as this changes.
So, essentially, Curator would:
-Start
-Connect to one of its configured ZK nodes
-Read the /zookeeper/config configuration
-Reconfigure itself based on that configuration
-Watch for future config updates.
I'm happy to start looking into this in a bit more detail unless someone
else has their heart set on it.
cheers
Cam
On Wed, Aug 6, 2014 at 10:53 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> An alpha of ZooKeeper 3.5.0 is being released. We should start thinking
> about how Curator should adjust to 3.5.x features, in particular
> https://issues.apache.org/jira/browse/ZOOKEEPER-107 (dynamic reconfig).
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801&version=12316644
>
> -Jordan