Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
Received-SPF: pass (athena.apache.org: domain of mckenzie.cam@gmail.com
 designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <etPan.53e22568.46e87ccd.795d@Jordans-MacBook-Pro.local>
References: <etPan.53e22568.46e87ccd.795d@Jordans-MacBook-Pro.local>
Date: Thu, 7 Aug 2014 15:44:54 +1000
Message-ID: 
 <CANykduYVMeR7UBcCxN3iWCdXyeSR3m2-ZmA74V=KXTSBaHOo=Q@mail.gmail.com>
Subject: Re: ZooKeeper 3.5.0 is coming
From: Cameron McKenzie <mckenzie.cam@gmail.com>
To: dev@curator.apache.org
Content-Type: multipart/alternative; boundary=001a113471dc9153b30500039655

--001a113471dc9153b30500039655
Content-Type: text/plain; charset=UTF-8

>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

--001a113471dc9153b30500039655--