From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christine Caulfield Date: Mon, 07 Sep 2009 07:42:38 +0100 Subject: [Cluster-devel] ccs_config_dump / ccs_config_validate In-Reply-To: <1252131148.6387.30.camel@cerberus.int.fabbione.net> References: <20090903192244.GB23923@redhat.com> <1252045015.339.139.camel@cerberus.int.fabbione.net> <20090904153753.GA26463@redhat.com> <1252086256.6387.25.camel@cerberus.int.fabbione.net> <20090904180612.GB26463@redhat.com> <1252131148.6387.30.camel@cerberus.int.fabbione.net> Message-ID: <4AA4AB5E.5090300@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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