1. and 2. Our cluster changes across all clusters happen on an infrequent basis (6 or fewer a month) and typically involve simple changes such as changing a SAN mount point (changing the device name or where to mount it,) adding a SAN mount or changing the user password for our fencing devices. 3. How we propogate the changes depends on who's making the change. I typically roll several changes (app and cluster) into the same maintenance window so I can bring down the cluster, at which point I simply vi the cluster.conf files (after testing the changes in staging, making backups, etc. etc. etc.) Other sys admins use ccs_tool to roll out simple changes. We don't have Conga deployed because, quite frankly, it wasn't enterprise ready when we last tested it (RHEL4 flavor, we have not deployed any RHEL5 clusters.) 4. While I prefer delimited flat files, there are occassions where a more structured config file is warranted (Apache jumps to mind.) I detest the use of XML as a straight-up configuration file. I am not an XML parser. That being said, what I would like to see for a command-line interface to configuration is something similar to what Augeas (augeas.net) aims to provide. A program that parses the existing config into a tree in memory, then acts as a shell to allow me to browse the tree, make changes as appropriate then validate the changes when it writes out the config or aborting with appropriate error messages on invalid settings. Using a "Augeas-type" tool might look something like the following: $ ccs_tool > get /files/etc/cluster/cluster.conf/1/name wilma > set /files/etc/cluster/cluster.conf/1/name fred > set /files/etc/cluster/cluster.conf/1/fence_domain/post_join_delay 10 > save > deploy Successfully deployed configuration version 97 to cluster "fred" > exit $ The "save" command would validate the configuration and write out the XML file. The "deploy" command would push the config to the other clusters the way css_tool does today. My understanding from the Augeas talk at the Redhat Summit is no lenses have been created that deal with XML-formatted files and David believes it's possible to do, he just simply hasn't tried it yet. I absolutely do not want to install X just to use system-config-cluster. We have clusters around the world and the latency imposed by the network on top of the latency of forwarding X over ssh is too painful. Our half dozen cluster admins all share this view. 5. Does it have to be LDAP? Can you make it a pluggable architecture w/ API so we can use whatever backend we want (MySQL/Postgres/SQLite, LDAP, Active Directory, DT+BG server*, etc.)? This feature should be optional, though. Centralized management of cluster configurations would be nice but, as others have said, introduces possible dependencies and points of failure. *Duct Tape and Bubble Gum --Jeff Sr. Systems Engineer/Performance Engineer OpSource, Inc. http://www.opsource.net "Your Success is Our Success" > -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx > [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of David Teigland > Sent: Monday, June 23, 2008 12:16 PM > To: linux-cluster@xxxxxxxxxx > Subject: RFC: updating cluster.conf > > Hi, > > We're looking into how cluster.conf updates should be done in future > versions and we'd like some feedback about how you currently > do this, and > what you'd like to see. > > 1. How often do you update cluster.conf? ("Never" would be valuable > feedback.) > > 2. What changes do you make? e.g. add nodes, change fencing settings, > add or change rgmanager settings. > > 3. How do you currently update cluster.conf? Cluster online > or offline? > Manually scp to all nodes? ccs_tool? conga? What do you > like and not > like about the method you use now? > > 4. How would you like to do updates to cluster.conf in the future? > Conga (graphical management interface)? Command line program that > updates /etc/cluster/cluster.conf on all cluster nodes? > Manually scp to all nodes? Other? > > 5. Would you like to use an LDAP server? All cluster nodes would read > cluster.conf info from the server; updates would just be made on > the server. > > Thanks, > Dave > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > > -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
