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

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

[Christine Caulfield]

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.

Chrissie
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: verify1.patch
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20090923/8a08e60d/attachment.ksh>

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

[Fabio M. Di Nitto]

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

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

Thanks
Fabio

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

[Christine Caulfield]

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

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

[Fabio M. Di Nitto]

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.

Fabio

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

[Christine Caulfield]

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


Here's a revised patch that adds fail,warn & none to the -D switch and 
also adds it to cman_tool join

Chrissie

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: validate.patch
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20090928/4473014a/attachment.ksh>