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

[Cluster-devel] ccs_config_dump / ccs_config_validate

On Thu, Sep 03, 2009 at 01:49:01PM +0000, Fabio M. Di Nitto wrote:
> config validation: improve shell wrapper
> add more error checking across the path and make ccs_config_validate
> error unique vs xmlling.

These are the kinds of tools users get excited about (for good reason), and
here's what I think they'll be expecting/wanting to do with them (again for
good reason).  (Note, I'm *not* describing what these commands actually do
right here, just what users might expect and want.)

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

ccs_config_dump > file.conf
- should dump the entire contents of running corosync confdb in xml format
- just an xml view of corosync-objctl
- It should be ok to:
  ccs_config_dump > file.conf, ccs_config_validate file.conf
- 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?)
- the dump command should not validate

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

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.

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

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.

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

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.
More sense would be to add the --dry-run option to the actual load command.
I'll have to look more closely at how the loading happens to make better


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