From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Mon, 23 Jun 2008 10:51:34 -0500 Subject: [Cluster-devel] cluster3 config system Message-ID: <20080623155134.GA19528@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It seems there's been some confusion about what the config system (ccs replacement) should be and do in cluster3. There were just two ideas I offered way back at the beginning: 1. Move the update mechanism outside the config system. 2. What remains is the part that reads the local cluster.conf file. This small and simple remainder should be merged into cman. Another idea that emerged was, 3. Add the option to get cluster.conf from an LDAP server. My impression, from casually following the progress, was that 2 and 3 were largely done, but I wasn't sure what the status of 1 was. An illustration I've often used for 1, is "manually scp cluster.conf to all cluster nodes". The point of the illustration is that the update mechanism should be external to the config system. I've always expected that some higher level program would actually make it simpler than manual scp. I think it would be great if this "higher level program" were conga, or one of conga's components. If enough customers use conga, I really think this should be the solution for auto-updates (manual updates via scp would always be possible). If too few customers use conga, then we may need to write some new "higher level program" to do it via command line, but it shouldn't be any more complex or less intuitive than "scp to all nodes". There aren't any cluster2 (RHEL5) compatibily issues here. cluster2 and cluster3 nodes can coexist in a cluster just fine as long as they are using matching cluster.conf files.