curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: ZooKeeper 3.5.0 is coming
Date Thu, 06 Nov 2014 16:07:39 GMT
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message