[Pacemaker] is ccs as racy as it feels?

[Brian J. Murrell]

So, I'm trying to wrap my head around this need to migrate to pacemaker
+CMAN.  I've been looking at
http://clusterlabs.org/quickstart-redhat.html and
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/

It seems "ccs" is the tool to configure the CMAN part of things.

The first URL talks about using ccs to create a local configuration and
then "copy" that around to the rest of the cluster.  Yuck.

The first URL doesn't really cover how one builds up clusters (i.e. over
time) but assumes that you know what your cluster is going to look like
before you build that configuration and says nothing about what to do
when you decide to add new nodes at some later point.  I would guess
more "ccm -f /etc/cluster/cluster.conf" and some more copying around
again.  Does anything need to be prodded to get this new configuration
that was just copied?  I do hope just "prodding" and not a restart of
all services including pacemaker managed resources.

The second URL talks about ricci for propagating the configuration
around.  But it seems to assume that all configuration is done from a
single node and then "sync'd" to the rest of the cluster with ricci in a
"last write wins" sort of work-flow.

So unlike pacemaker itself where any node can modify the configuration
of the CIB (raciness in tools like crm aside), having multiple nodes
using ccs feels quite dangerous in a "last-write-wins" kind of way.  Am
I correct?

This makes it quite difficult to dispatch the task of configuring the
cluster out to the nodes that will be participating in the cluster --
having them configure their own participation.  This distribution of
configuration tasks all works fine for pacemaker-proper (if you avoid
tools like crm) but feels like it's going to blow up when having
multiple nodes trying to add themselves and their own configuration to
the CMAN configuration -- all in parallel.

Am I correct about all of this?  I hope I am not, because if I am this
all feels like a (very) huge step backward from the days where corosync
+pacemaker configuration could be carried out in parallel, on multiple
nodes without having to designate particular (i.e. one per cluster)
nodes as the single configuration point and feeding these designated
nodes the configuration items through a single-threaded work queue all
just to avoid the races that didn't exist using just corosync+pacemaker.

Cheers,
b.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.clusterlabs.org/pipermail/pacemaker/attachments/20131209/1e8ff01c/attachment-0002.sig>