On Mon, Jun 23, 2008 at 12:16 PM, David Teigland <teigland@xxxxxxxxxx> wrote:
Infrequently, we pretty much only update it as we grow or shrink the cluster.
We add and remove nodes.
We have a product that ships to customers and uses RHCS for clustering support. Our config files are generated on each node and we've had problems in the past with the current system of using the cluster.conf not only as a configuration file but also as a config cache. We'd like a mechanism to allow us to generate the configuration files and then manually tell each node to move to them.
We'll continue to do it as we do above, so from your perspective, you can count us in the manual camp.
This adds a dependency on an external server or will cause undue pain in trying to keep the LDAP databases in sync if running on the nodes. From our perspective, this sounds like a regression.
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.)
Infrequently, we pretty much only update it as we grow or shrink the cluster.
2. What changes do you make? e.g. add nodes, change fencing settings,
add or change rgmanager settings.
We add and remove nodes.
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?
We have a product that ships to customers and uses RHCS for clustering support. Our config files are generated on each node and we've had problems in the past with the current system of using the cluster.conf not only as a configuration file but also as a config cache. We'd like a mechanism to allow us to generate the configuration files and then manually tell each node to move to them.
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?
We'll continue to do it as we do above, so from your perspective, you can count us in the manual camp.
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.
This adds a dependency on an external server or will cause undue pain in trying to keep the LDAP databases in sync if running on the nodes. From our perspective, this sounds like a regression.
-z
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
