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

Re: [Cluster-devel] ccs_config_dump / ccs_config_validate



On 05/09/09 07:12, Fabio M. Di Nitto wrote:
On Fri, 2009-09-04 at 13:06 -0500, David Teigland wrote:
On Fri, Sep 04, 2009 at 07:44:16PM +0200, Fabio M. Di Nitto wrote:
ccs_config_validate /path/to/file
. just xmllint on file
. (do not load file into any libs)

ccs_config_validate --load-test /path/to/file
. load file into xmlconfig and cmanpreconfig
. dump result to tmpfile
. xmllint tmpfile
. rm tmpfile

ccs_config_validate --load-test
. depending on /etc/sysconfig/
. load /etc/cluster/cluster.conf into xmlconfig and cmanpreconfig, or
. load other source like ldap into cmanpreconfig
. dump result to tmpfile
. xmllint tmpfile
. rm tmpfile

Ok now I see what you mean. It's easily doable. I was planning to add
help and options support to ccs_config_validate anyway.

All of the above is easily doable, but I think i would still prefer to
have the --load-test by default because it's what is really going to run
on the cluster and document maybe a --validate-file to validate only the
file since it is a special case (there is no easy equivalent for ldap or
other loaders at the moment).

Dunno, I'm just trying to put myself in the place of the user using these
tools and thinking about what would make most sense to them.  We optimize the
usage for them, not for code that calls the tools.  Perhaps we should have
both:

ccs_config_validate --test-file /path/to/file
. validates the file directly

ccs_config_validate --test-load [/path/to/file]
. validates the file after passing it through config libs which add default
   values that are not specified in file
. without file, /etc/sysconfig is used to determine the config source,
   e.g. /etc/cluster/cluster.conf, or ldap

Then I wouldn't mind ccs_config_validate called with no options or args to
default to the later.  In that case it would be nice to see it print the full
command that it's actually running, just to remove some of the "magical"
quality, e.g.

ccs_config_validate
ccs_config_validate --test-load /etc/cluster/cluster.conf
ok

Ok let's do it this way. We define all options and document them for
what they do and we default to a "load-test" with values
from /etc/sysconfig (or equivalent) if no options are given.

I'll think about showing what we do internally but I am generally
against it for 2 reasons:

- it clutters the output a lot (and errors from xmllint are already bad
enough).

- it can be confusing to users to see pipes and some shell magic
commands happening. After all we don't print all the calls we do
everywhere because the user doesn't really need to know all the internal
magic.


I agree. Just because it's a script that does the work doesn't mean it should automatically show its working. If the user wants to do that then there are -v or -x switches to the shell itself. If the whole operation was written in C you wouldn't get it to print its source code out before running ... would you ?


Chrissie


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