Raghu S commented on ZOOKEEPER-107:

Using a URL for obtaining a list of servers may not be acceptable in all 
environments. The URL will have to highly available otherwise the clients won't 
connect after a restart. It applies to ZK peers as well, a peer won't be able 
to restart if the URL is down at the time of peer restart. So I believe (1) is 
a better choice here -- the cluster needs to be self-contained.

IIUC, using a ZK node to expose the cluster config would mean that the cluster 
can't be created unless the cluster config is pre-populated? We need to first 
create a log file that contains a config node that has the initial cluster 
members, copy them to all the nodes and power them on to create the cluster? 
Once the cluster is formed, new nodes can be admitted to the cluster by having 
a quorum commit the new server name in the cluster config. 

Another alternative would be to have a single node come up first (with the log 
file pre-populated to contain a single server in the cluster config node) and 
then have all other servers join one at a time? This sounds a bit weird to me 
in that the first node will have to form a single node cluster in the 
beginning, which is an oxymoron :)

> Allow dynamic changes to server cluster membership
> --------------------------------------------------
>                 Key: ZOOKEEPER-107
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
>             Project: Zookeeper
>          Issue Type: Improvement
>          Components: server
>            Reporter: Patrick Hunt
> Currently cluster membership is statically defined, adding/removing hosts 
> to/from the server cluster dynamically needs to be supported.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

Reply via email to