[Cluster-devel] cluster3 config system

[Cluster-devel] cluster3 config system

[David Teigland]

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.

[Cluster-devel] cluster3 config system

[Fabio M. Di Nitto]

On Mon, 23 Jun 2008, David Teigland wrote:

> 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.

This is a bit more clear than what we originally discussed and can be 
easily achieved by modifing ccsconfig.lcrso. Loading the config from the 
file is dead easy. The problem to notify nodes about updates needs some 
investigation from my side because it might add an extra tool/interface to 
an existing tool. _Maybe_ we can even consider using some fancy interfaces 
like inotify to detect a config change and propagate across the cluster.

In any case cman will never read the config directly. It would be the 
"ccsais" plugin doing it (can be renamed to fileconfig or whatever..), 
mainly because we don't want cman to become "Alpha and Omega".

If we move the config loader within ccsais, the actual ccsd can be either 
removed, or turned into an "update mechanism" only. There would be tons of 
unrequired code that can disappear from ccsd and it would become a 
realitevely slim daemon to have around (optional and only for who wants 
it).

> Another idea that emerged was,
>
> 3. Add the option to get cluster.conf from an LDAP server.

This was a requirement from customers AFAIK.

> 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.

In order to achieve 1,2 and 3 we had to modularize and abstract a lot of 
bits. All the abstraction layer and modularization is done.

It is possible to replace ccsd with "something else" but that something 
else needs to be written (like LDAP config loader).
Theoretically speaking you can use openais config file and format right 
now to load a replacement for cluster.conf.

> 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.

This is a strong assumption IMHO.

The same moment in which you advertise backward compatibility, you can 
expect people to switch a bunch of nodes from 2 to 3 in the same cluster 
to test services and so on. That might involve configuration changes as 
well. If there is no common update mechanism, the user experience will be 
aweful.

The big picture (as i see it) is a bit more complicated and i see a lot of 
corner cases where it desirable to change configs on the fly in a mixed 
cluster.

Fabio

--
I'm going to make him an offer he can't refuse.