[Cluster-devel] ccs_config_dump / ccs_config_validate

[Cluster-devel] ccs_config_dump / ccs_config_validate

[David Teigland]

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

Dave

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

On Thu, 2009-09-03 at 14:22 -0500, David Teigland wrote:

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

As it is implemented now, ccs_config_validate does only validate the
config. It's not loaded in the running cluster.

> ccs_config_dump > file.conf
> - should dump the entire contents of running corosync confdb in xml format

We can only dump safely and reliably the contents of <cluster...
The corosync confdb/objdb contains objects that are not "xml friendly"
and filtering them is a nightmare. We have been down that path before
with libccs and we had to move back to <cluster.. only contents.

> - just an xml view of corosync-objctl

It is just an xml view of <cluster.. entries in objdb.

> - It should be ok to:
>   ccs_config_dump > file.conf, ccs_config_validate file.conf

Already possible now.

> - 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?)

It's already possible.

> - the dump command should not validate

dump doesn't validate or take any action. It's really just a dump of the
objdb in xml format.

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

I think it's sane to have runtime info validated by cluster.rng. They
are config options after all and a cross check between code and
validator could spot possible bugs.

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

I don't see any easy other way around that with the current
implementation.

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

this is what config_validate does already. The result is not loaded in
the runtime environment.

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

I am not 100% sure I understand what you mean here.

Would you like config_validate /file.conf to save a new file with the
extra bits that cman or other subsystems create at runtime?


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

I really don't understand what you are saying here.

ccs_config_dump has a dual more operation.

Invoked standalone (clean environment) it dumps the runtime config
(assuming corosync is running or it will fail).

Invoked with proper env vars (as config_validate does) it uses an
"offline" objdb instance and not the runtime (same as --dry-run
basically). This is required for us to interface with other loaders !=
xml such as ldap, load the information in a standalone objdb and be able
to dump them in XML format for whatever use.

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

I think the only misunderstanding here is the ccs_config_dump dual mode
operation, but then.. I am not sure I understand why you think they are
backwards.

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

config_validate never loads the config in the runtime environment but it
uses the offline objdb instance. This step is absolutely mandatory for
us to abstract from the config source that could be anything (xml, ldap,
corosync.conf, etc).

Fabio

[Cluster-devel] ccs_config_dump / ccs_config_validate

[David Teigland]

On Fri, Sep 04, 2009 at 08:16:55AM +0200, Fabio M. Di Nitto wrote:
> On Thu, 2009-09-03 at 14:22 -0500, David Teigland wrote:
> 
> > ccs_config_validate file.conf
> > - just run xmllint --relaxng cluster.rng file.conf and report errors,
> >   don't do anything more
> 
> As it is implemented now, ccs_config_validate does only validate the
> config. It's not loaded in the running cluster.

It's first loaded into xmlconfig and cmanpreconfig, then validated.  That's
the bit that's strange or confusing to a user.  A user would generally expect
this command to validate precisely the file they provide, not a transmogrified
version of it.

> > ccs_config_dump > file.conf
> > - should dump the entire contents of running corosync confdb in xml format
> 
> We can only dump safely and reliably the contents of <cluster...
> The corosync confdb/objdb contains objects that are not "xml friendly"
> and filtering them is a nightmare. We have been down that path before
> with libccs and we had to move back to <cluster.. only contents.

OK, I looked more@this and now see that you're duplicating things like
totem.token and logging under both cluster and the root,

# corosync-objctl | grep token
cluster.totem.token=2000
totem.token=2000

I'd feared we'd miss those by just dumping cluster.

> >   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?
> 
> I am not 100% sure I understand what you mean here.

Here are usages I think would make sense to users:

ccs_config_dump
. dumps cluster section of confdb

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

Dave

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

On Fri, 2009-09-04 at 10:37 -0500, David Teigland wrote:
> On Fri, Sep 04, 2009 at 08:16:55AM +0200, Fabio M. Di Nitto wrote:
> > On Thu, 2009-09-03 at 14:22 -0500, David Teigland wrote:
> > 
> > > ccs_config_validate file.conf
> > > - just run xmllint --relaxng cluster.rng file.conf and report errors,
> > >   don't do anything more
> > 
> > As it is implemented now, ccs_config_validate does only validate the
> > config. It's not loaded in the running cluster.
> 
> It's first loaded into xmlconfig and cmanpreconfig, then validated.  That's
> the bit that's strange or confusing to a user.  A user would generally expect
> this command to validate precisely the file they provide, not a transmogrified
> version of it.

Right because we want to validate the config that is going to be running
if that cluster.conf is going to be pushed into production. See my other
comments below.


> 
> > >   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?
> > 
> > I am not 100% sure I understand what you mean here.
> 
> Here are usages I think would make sense to users:
> 
> ccs_config_dump
> . dumps cluster section of confdb

Ok this is done and working. Let's remove it from the list :)

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

Fabio

[Cluster-devel] ccs_config_dump / ccs_config_validate

[David Teigland]

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

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

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.

Fabio

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Christine Caulfield]

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

[Cluster-devel] ccs_config_dump / ccs_config_validate

[David Teigland]

On Mon, Sep 07, 2009 at 07:42:38AM +0100, Christine Caulfield wrote:
> >- 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.

My whole point is that it's the plain "ccs_config_validate" that's confusing
to users, and printing more detail makes it *less* confusing!

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

Setting aside absurdities :-), I'm not convinced either of you took enough
time to consider the real issue behind the unusual idea.  Please try to forget
everything you know about ccs/confdb/xmlconfig/ldapconfig/cmanpreconfig and
put yourself the position of a user trying to debug/diagnose/understand what's
happening with their cluster.  These tools are for them, not for cman_tool to
use, despite how they began.

My motivation is that a plain ccs_config_validate is a "magical" command; a
user has no clue what it's doing, which is the first key step in understanding
what to make of the result.  As such, I think we should encourage the use of
explicit commands whenever possible, like:

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

Echoing one of those for a plain ccs_config_validate is probably not the best
way to communicate helpful info the user.  So let's put some thought into
something *better* and less magical.

How about using -v (verbose) like,

ccs_config_validate --test-file new.conf
ok

ccs_config_validate -v --test-file new.conf
test file new.conf
ok


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

ccs_config_validate -v --test-file /etc/cluster/cluster.conf
test file /etc/cluster/cluster.conf
ok


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

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


ccs_config_validate --test-load
ok

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


ccs_config_validate
ok

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


ccs_config_validate --test-load
ok

ccs_config_validate -v --test-load
test load ldap://...
ok


ccs_config_validate
ok

ccs_config_validate -v
test load ldap://...
ok

Dave

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

On Tue, 2009-09-08 at 11:01 -0500, David Teigland wrote:
> On Mon, Sep 07, 2009 at 07:42:38AM +0100, Christine Caulfield wrote:
> > >- 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.
> 
> My whole point is that it's the plain "ccs_config_validate" that's confusing
> to users, and printing more detail makes it *less* confusing!

did you try the -v option in the version I committed a few hours ago
based on your previous suggestions? :)

Skipping the rest of the email for obvious reasons :)))

So unless I am missing something, the current implementation does
exactly what you have been asking for.

Fabio

[Cluster-devel] ccs_config_dump / ccs_config_validate

[David Teigland]

On Tue, Sep 08, 2009 at 06:49:29PM +0200, Fabio M. Di Nitto wrote:
> did you try the -v option in the version I committed a few hours ago
> based on your previous suggestions? :)
> 
> Skipping the rest of the email for obvious reasons :)))
> 
> So unless I am missing something, the current implementation does
> exactly what you have been asking for.

Yes, I think it has all the capabilities we need, but the usage, options, and
output are still quite confusing.  Here's what I'd like to see:

ccs_config_validate [options] [-f|-l] [/path/to/file]

Options:
  -f /path/to/file      Validate the config from the specified file.

  -l [/path/to/file]    Validate the config from the specified file
                        (or other source using /etc/sysconfig/cman),
                        after loading it into config libs which add
                        default values.

  -v                    Produce verbose output
  -d                    Produce debug output
  -V                    Print program version information, then exit
  -h                    Print this help, then exit

Debugging options:
  -C config_loader      Override config plugin loader
  -t tempfile           Force temporay file to tempfile
  -n                    Do not remove temporary file
  -o                    Overwrite temporary file (dangerous)


verbose option would add "test file" / "test load" output   

> ccs_config_validate -v -f /path/to/file
test file /path/to/file

> ccs_config_validate -v -l /path/to/file
test load /path/to/file

> ccs_config_validate -v -l
test load [/path/to/file | ldap/url]

> ccs_config_validate -v
test load [/path/to/file | ldap/url]

debug option would add config libs and temp file output

> ccs_config_validate -v -d -l
test load [/path/to/file | ldap/url]
config libs [xmlconfig|ldapconfig]:cmanpreconfig
temporary file /tmp/tmp.cbtgJ20313

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

On Tue, 2009-09-08 at 13:34 -0500, David Teigland wrote:
> On Tue, Sep 08, 2009 at 06:49:29PM +0200, Fabio M. Di Nitto wrote:
> > did you try the -v option in the version I committed a few hours ago
> > based on your previous suggestions? :)
> > 
> > Skipping the rest of the email for obvious reasons :)))
> > 
> > So unless I am missing something, the current implementation does
> > exactly what you have been asking for.
> 
> Yes, I think it has all the capabilities we need, but the usage, options, and
> output are still quite confusing.  Here's what I'd like to see:
> 
> ccs_config_validate [options] [-f|-l] [/path/to/file]
> 
> Options:
>   -f /path/to/file      Validate the config from the specified file.
> 
>   -l [/path/to/file]    Validate the config from the specified file
>                         (or other source using /etc/sysconfig/cman),
>                         after loading it into config libs which add
>                         default values.
> 
>   -v                    Produce verbose output
>   -d                    Produce debug output
>   -V                    Print program version information, then exit
>   -h                    Print this help, then exit

Be aware that debug in shell world has a different meaning that what we
are used to.

I would prefer to skip debug completely and leave verbose to print
everything it prints now.

Fabio

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

On Tue, 2009-09-08 at 13:34 -0500, David Teigland wrote:
> On Tue, Sep 08, 2009 at 06:49:29PM +0200, Fabio M. Di Nitto wrote:
> > did you try the -v option in the version I committed a few hours ago
> > based on your previous suggestions? :)
> > 
> > Skipping the rest of the email for obvious reasons :)))
> > 
> > So unless I am missing something, the current implementation does
> > exactly what you have been asking for.
> 
> Yes, I think it has all the capabilities we need, but the usage, options, and
> output are still quite confusing.  Here's what I'd like to see:
> 
> ccs_config_validate [options] [-f|-l] [/path/to/file]
> 
> Options:
>   -f /path/to/file      Validate the config from the specified file.
> 
>   -l [/path/to/file]    Validate the config from the specified file
>                         (or other source using /etc/sysconfig/cman),
>                         after loading it into config libs which add
>                         default values.
> 
>   -v                    Produce verbose output
>   -d                    Produce debug output
>   -V                    Print program version information, then exit
>   -h                    Print this help, then exit
> 
> Debugging options:
>   -C config_loader      Override config plugin loader

Forgot to mention this one.. being able to override is not debugging.

It's very useful if I am migrating from one config system to another.

For example I just imported current cluster.conf into LDAP, before I
change default settings, I can ask to validate the config there (or
whatever possible combination).

Fabio

[Cluster-devel] ccs_config_dump / ccs_config_validate

[David Teigland]

On Tue, Sep 08, 2009 at 10:50:46PM +0200, Fabio M. Di Nitto wrote:
> >   -d                    Produce debug output
>
> I would prefer to skip debug completely and leave verbose to print
> everything it prints now.

ok

> > Debugging options:
> >   -C config_loader      Override config plugin loader
> 
> Forgot to mention this one.. being able to override is not debugging.

just remove "Debugging options", all those options are actually useful.

> For example I just imported current cluster.conf into LDAP, before I
> change default settings, I can ask to validate the config there (or
> whatever possible combination).

Would it be useful to allow

ccs_config_validate -l [/path/to/file | ldap/url] ?

(To me, the sysconfig/cman nonsense is actually the part that makes all this
too complicated for normal humans to keep straight.  99% of users will not be
using sysconfig/cman, so let's be sure not to sacrifice clarity for the sake
of the 1%.)

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

On Wed, 2009-09-09 at 10:42 -0500, David Teigland wrote:
> On Tue, Sep 08, 2009 at 10:50:46PM +0200, Fabio M. Di Nitto wrote:
> > >   -d                    Produce debug output
> >
> > I would prefer to skip debug completely and leave verbose to print
> > everything it prints now.
> 
> ok
> 
> > > Debugging options:
> > >   -C config_loader      Override config plugin loader
> > 
> > Forgot to mention this one.. being able to override is not debugging.
> 
> just remove "Debugging options", all those options are actually useful.

Ok.

> 
> > For example I just imported current cluster.conf into LDAP, before I
> > change default settings, I can ask to validate the config there (or
> > whatever possible combination).
> 
> Would it be useful to allow
> 
> ccs_config_validate -l [/path/to/file | ldap/url] ?
> 
> (To me, the sysconfig/cman nonsense is actually the part that makes all this
> too complicated for normal humans to keep straight.  99% of users will not be
> using sysconfig/cman, so let's be sure not to sacrifice clarity for the sake
> of the 1%.)

The ldap config is complex and requires at least 2 env vars to be set.
I'll need to check with Chrissie if it's possible to pass them embedded
in the URL as I am really not the ldap expert.

The other problem is that we don't want to special case too much on the
command line because it means keeping the tool constantly up to date
with all possible loaders and custom loaders that users could/might
write.

The whole point of reading the configuration from sysconfig/cman is that
once the user sets it to a custom loader, ccs_config_validate picks it
up automatically without effort that would otherwise require both coding
on our side and extra parameters from the user to validate.

Fabio

[Cluster-devel] ccs_config_dump / ccs_config_validate

[David Teigland]

On Wed, Sep 09, 2009 at 07:24:53PM +0200, Fabio M. Di Nitto wrote:
> The other problem is that we don't want to special case too much on the
> command line because it means keeping the tool constantly up to date
> with all possible loaders and custom loaders that users could/might
> write.

Hm, ok, I'm not sure how to respond to alternate universes arguments in this
context :-)

> The whole point of reading the configuration from sysconfig/cman is that
> once the user sets it to a custom loader, ccs_config_validate picks it
> up automatically without effort that would otherwise require both coding
> on our side and extra parameters from the user to validate.

Yes, I understand the point of sysconfig/cman.  If it were me, everything
everywhere would assume /etc/cluster/cluster.conf, the code would be simpler
and more robust, the tools likewise, and 99.9% of users would be very happy.
To the .1%, sorry.

That puts us at opposite ends of the spectrum, and I suspect the ccs tools are
now somewhere in the middle, so I'm fine with them.

Dave

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Fabio M. Di Nitto]

On Wed, 2009-09-09 at 13:09 -0500, David Teigland wrote:

> 
> > The whole point of reading the configuration from sysconfig/cman is that
> > once the user sets it to a custom loader, ccs_config_validate picks it
> > up automatically without effort that would otherwise require both coding
> > on our side and extra parameters from the user to validate.
> 
> Yes, I understand the point of sysconfig/cman.  If it were me, everything
> everywhere would assume /etc/cluster/cluster.conf, the code would be simpler
> and more robust, the tools likewise, and 99.9% of users would be very happy.
> To the .1%, sorry.

We already have users that need different config file. I use that
feature myself a lot for my test clusters :) it's really handy when you
want to swap configs around without rename/symlinks etc...

Fabio

[Cluster-devel] ccs_config_dump / ccs_config_validate

[Christine Caulfield]

On 09/09/09 18:24, Fabio M. Di Nitto wrote:
> On Wed, 2009-09-09 at 10:42 -0500, David Teigland wrote:
>> On Tue, Sep 08, 2009 at 10:50:46PM +0200, Fabio M. Di Nitto wrote:
>>>>    -d                    Produce debug output
>>>
>>> I would prefer to skip debug completely and leave verbose to print
>>> everything it prints now.
>>
>> ok
>>
>>>> Debugging options:
>>>>    -C config_loader      Override config plugin loader
>>>
>>> Forgot to mention this one.. being able to override is not debugging.
>>
>> just remove "Debugging options", all those options are actually useful.
>
> Ok.
>
>>
>>> For example I just imported current cluster.conf into LDAP, before I
>>> change default settings, I can ask to validate the config there (or
>>> whatever possible combination).
>>
>> Would it be useful to allow
>>
>> ccs_config_validate -l [/path/to/file | ldap/url] ?
>>
>> (To me, the sysconfig/cman nonsense is actually the part that makes all this
>> too complicated for normal humans to keep straight.  99% of users will not be
>> using sysconfig/cman, so let's be sure not to sacrifice clarity for the sake
>> of the 1%.)
>
> The ldap config is complex and requires at least 2 env vars to be set.
> I'll need to check with Chrissie if it's possible to pass them embedded
> in the URL as I am really not the ldap expert.
>

In theory you can. In practise it doesn't work, unfortunately :-(

Chrissie