Hi Sergei, I'm doing something similar for ZOOKEEPER-107 (dynamically changing cluster config, eliminating the need for rolling restarts). I've split the config file in two parts: in the main configuration file I add a line "membershipFile=<path>" and put all membership definitions in that new file <path>. Membeship info is any of the following: server, weight, group, and peertype (there is also a version of the config, which is automatically generated). If there is no membership file, I consider this to be standalone more. When reconfiguration happens, the membership file is automatically updated by the server. As you mentioned, the memberhip file is exactly the same for all members of a configuration. Client library (both Java and C) allow adding/removing servers from the cluster, changing a server's quorum and leader election ports, their type (observer/participant), or just giving a new membership file which will be used to update the configuration.
I'm currently working on documenting this, and hope to be able to add this to the following release of ZooKeeper. Best Regards, Alex > -----Original Message----- > From: Sergei Babovich [mailto:[email protected]] > Sent: Friday, July 22, 2011 8:36 AM > To: [email protected] > Subject: Using system property to configure clientPortAddress > > Hi, > In our deployment to simplify managing of a cluster we'd like to > separate configuration common for the whole cluster from the > configuration specific to a particular node. Using such approach in > order to reconfigure cluster we would just need to update single shared > config file and perform rolling restart. At this moment all nodes should > use all the same configuration parameters except clientPort and > clientPortAddress (we need to explicitly provide them to allow various > deployment scenarios for production and qa). Zookeeper already > incorporates abilities to achieve having shared configuration with > adjusting some local parameters through system properties (for example > *zookeeper.snapCount*), but not all configuration parameters supported > including two that we are interested in. Is there any particular reason > why some config parameters have system property equivalent and others do > not? Is there any other way already to separate cluster wide > configuration from node specific? > > Best regards, > Sergei > > > This e-mail message and all attachments transmitted with it may contain > privileged and/or confidential information intended solely for the use of the > addressee(s). If the reader of this message is not the intended recipient, you > are hereby notified that any reading, dissemination, distribution, copying, > forwarding or other use of this message or its attachments is strictly > prohibited. If you have received this message in error, please notify the > sender immediately and delete this message, all attachments and all copies and > backups thereof.
