[Cluster-devel] [PATCH] STABLE3: enhance cman_tool to validate and distribute configuration files

[Christine Caulfield <ccaulfie@redhat.com>]

On 23/09/09 17:48, Fabio M. Di Nitto wrote:
> Hi Chrissie,
>
> On Wed, 2009-09-23 at 15:41 +0100, Christine Caulfield wrote:
>> This patch adds significant functionality to 'cman_tool version'. If -r0
>> is specified, then the configuration file is validated (using
>> ccs_config_validate), distributed around the cluster (if necessary,
>> using ccs_sync) and activated. This provides a single command to update
>> a configuration ... something people have been asking for for ages.
>
> wooooo
>
>>
>> I'm not 100% happy about bundling it into cman_tool version, but neither
>> am I convinced that this warrants another cman_tool sub-command ... so
>> if anyone has any better ideas please speak up.
>
> No more subcommands.. I think this is enough.
>
> The patch looks good but I think we need to add a few more details here
> and there...
>
> We agreed to have validation to work with 3 config options: off (-D),
> warning and fail hard. So I think -D could just take an option to
> none,warn,fail or something like that.

I'm not sure how useful this is in this situation. Distributing and 
loading an invalid configuration is not a useful thing to do, surely? 
And if you really insist on it, then I'd rather make it a two stage 
process of "oh, you're telling me it's broken", then "but I know better 
so do it anyway". Then there is some manual intervention to check the 
configuration is right - maybe it's a schema error on our part. But in 
many cases a bad config either won't load at all, or will make a mess of 
your cluster - and once it's been copied around you might have lost your 
valid backup!


> I'd like to see an option to disable sync too. Even if we have ccs_sync,
> not everybody might be using conga/luci and can at least allow them to
> do it gently.

Agreed, I've added -S



> I don't recall exactly why we needed to propagate COROSYNC_CONFIG_IFACE
> from cman_tool invokation. I am sure there was a very good reason for
> that. If so we might have to propagate also other COROSYNC_ envvars
> including LDAP bits.. because they will need to be available to
> ccs_config_validator and I'll also need to make the validator a bit less
> picky about overriding the environment if the environment is already
> loaded (this is my task of course).

We need COROSYNC_CONFIG_IFACE so that the validation process knows what 
configuration system corosync actually used to load it's configuration 
from ... and where it will reload the new one from. You can't change 
this on the fly but you CAN edit config files to take effect next 
reboot. So we have to use the active system.

I agree that LDAP needs other env variables but am not quite sure how to 
add them. Either we hard-code into cman_tool the variables we can use, 
or we copy all variables starting with COROSYNC_ into objdb and extract 
them again before validation!

Chrissie