[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

On Thu, 2009-09-03 at 14:22 -0500, David Teigland wrote:

> ccs_config_validate file.conf
> - just run xmllint --relaxng cluster.rng file.conf and report errors,
>   don't do anything more

As it is implemented now, ccs_config_validate does only validate the
config. It's not loaded in the running cluster.

> ccs_config_dump > file.conf
> - should dump the entire contents of running corosync confdb in xml format

We can only dump safely and reliably the contents of <cluster...
The corosync confdb/objdb contains objects that are not "xml friendly"
and filtering them is a nightmare. We have been down that path before
with libccs and we had to move back to <cluster.. only contents.

> - just an xml view of corosync-objctl

It is just an xml view of <cluster.. entries in objdb.

> - It should be ok to:
>   ccs_config_dump > file.conf, ccs_config_validate file.conf

Already possible now.

> - It should be ok to:
>   ccs_config_dump > file.conf, edit file.conf, ccs_config_validate file.conf,
>   load/run with file.conf should be possible (cman_tool -r I think?)

It's already possible.

> - the dump command should not validate

dump doesn't validate or take any action. It's really just a dump of the
objdb in xml format.

> 
> (This requires adding a bunch of stuff to cluster.rng that people do not add
> to cluster.conf.  That should be ok.)

I think it's sane to have runtime info validated by cluster.rng. They
are config options after all and a cross check between code and
validator could spot possible bugs.

> The disconnect with the above is going to happen when the see that the dump
> has much more stuff than they put in their cluster.conf, and they're going to
> want to understand that.  I don't think it should be too difficult to explain
> that cman supplements a cluster.conf file with default values so the user
> doesn't have to enter them.

I don't see any easy other way around that with the current
implementation.

> 
> Conceptually, these are the kinds of things that make sense to a user, and
> would be useful for them.
> 
> Another usage: take a file.conf, add default cman stuff to it, and validate
> the result without making the result "active".

this is what config_validate does already. The result is not loaded in
the runtime environment.

>   To a user, this would make
> sense conceptually as "load file.conf with --dry-run".  And that's what cman
> actually wants to do prior to loading a new config.  So, my question is what
> does/should the command for "load file.conf with --dry-run" look like?

I am not 100% sure I understand what you mean here.

Would you like config_validate /file.conf to save a new file with the
extra bits that cman or other subsystems create at runtime?


> Currently, it appears that it's just "ccs_config_validate", but that makes no
> conceptual sense based on the logical view of what dump and validate mean to a
> user.  Looking at what ccs_config_validate does just makes it more confusing:
> ccs_config_dump > tmp.conf; xmllint tmp.conf; rm tmp.conf ... not only does
> validate not do what you'd think, but dump doesn't either.

I really don't understand what you are saying here.

ccs_config_dump has a dual more operation.

Invoked standalone (clean environment) it dumps the runtime config
(assuming corosync is running or it will fail).

Invoked with proper env vars (as config_validate does) it uses an
"offline" objdb instance and not the runtime (same as --dry-run
basically). This is required for us to interface with other loaders !=
xml such as ldap, load the information in a standalone objdb and be able
to dump them in XML format for whatever use.

> So, I think the problem here is that we're providing tools to users who are
> going to want to use them in a logical fashion, but they have rather backwards
> and confusing behaviors.  It'll take more work to do it sensibly, but I think
> it'll be worth it to get this right.  A couple ideas...

I think the only misunderstanding here is the ccs_config_dump dual mode
operation, but then.. I am not sure I understand why you think they are
backwards.

> Something like "ccs_config_validate --dry-run file.conf" could make sense as
> "load file.conf with --dry-run", but it implies that ccs_config_validate
> without --dry-run would try to load file.conf, which it doesn't and shouldn't.

config_validate never loads the config in the runtime environment but it
uses the offline objdb instance. This step is absolutely mandatory for
us to abstract from the config source that could be anything (xml, ldap,
corosync.conf, etc).

Fabio