[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 Thu, 2009-09-24 at 10:05 +0100, Christine Caulfield wrote:
> 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?

Right, but I think the original idea was not to force validation by
default because we don't know how good our schema is.

So I would prefer the 3 options and switch gently to a more enforcing
version as our schema grows and gets perfected.

Getting warnings back from users will help us in this process.

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

Agreed, but can we do it in 2 stages? first soft, then enforcing?

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

Agreed of course.

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

Oh right.. thanks for reminding me.

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

I would prefer to go for the second solution as we also need it for
alternative config files and so on.

I'll take the ball to look into ccs_config_validation envvar overrides.


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