curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioannis Canellos <ioca...@gmail.com>
Subject Re: ZooKeeper 3.5.0 is coming
Date Thu, 06 Nov 2014 15:45:52 GMT
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 <iocanel@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
> <jordan@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
>> <jordan@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

Mime
View raw message