Benjamin Reed commented on ZOOKEEPER-107:

sounds great henry! it would be great if you could work on this.

i think we have two strategies:

1) have the cluster agree on a list of servers and use the atomic broadcast to 
agree on changes. (this might be a bit more difficult with the flexible quorum 
configuration. right flavio?) this is mostly in line with your first three 
points. btw, i don't think you need to quiesce for this or even do the sync. i 
think you can do a conditional update.

2) use some external resource file indicated by a URL to define the machines 
that make up a cluster. this is in line with your last point and you hint at 
this with your first point.

i think the first approach is safer and more reliable. the second is easier to 
implement and easier to see what is going on, but i during transition time you 
have a problem as the resource file propagates through the cluster. (you could 
have different members with different views.)

the thing i was thinking of for the first option is exposing the cluster config 
through a znode '/.zookeeper/ensemble' or something like that. then changing 
the configuration would be as "simple" as conditionally setting a new version 
of that file. the tricky part is that you could only commit the change if you 
have a quorum of followers in both the old and the new configuration. this 
seems to be in line with what you are thinking correct?

> 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