From: David Teigland <teigland@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] ccs_config_dump / ccs_config_validate
Date: Fri, 4 Sep 2009 13:06:12 -0500 [thread overview]
Message-ID: <20090904180612.GB26463@redhat.com> (raw)
In-Reply-To: <1252086256.6387.25.camel@cerberus.int.fabbione.net>
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
Dave
next prev parent reply other threads:[~2009-09-04 18:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 19:22 [Cluster-devel] ccs_config_dump / ccs_config_validate David Teigland
2009-09-04 6:16 ` Fabio M. Di Nitto
2009-09-04 15:37 ` David Teigland
2009-09-04 17:44 ` Fabio M. Di Nitto
2009-09-04 18:06 ` David Teigland [this message]
2009-09-05 6:12 ` Fabio M. Di Nitto
2009-09-07 6:42 ` Christine Caulfield
2009-09-08 16:01 ` David Teigland
2009-09-08 16:49 ` Fabio M. Di Nitto
2009-09-08 18:34 ` David Teigland
2009-09-08 20:47 ` Fabio M. Di Nitto
2009-09-08 20:50 ` Fabio M. Di Nitto
2009-09-09 15:42 ` David Teigland
2009-09-09 17:24 ` Fabio M. Di Nitto
2009-09-09 18:09 ` David Teigland
2009-09-09 18:37 ` Fabio M. Di Nitto
2009-09-10 8:22 ` Christine Caulfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090904180612.GB26463@redhat.com \
--to=teigland@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).