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
