[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.


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!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]