[Cluster-devel] ccs_config_dump / ccs_config_validate

[Christine Caulfield <ccaulfie@redhat.com>]

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