----- "Lucas Meneghel Rodrigues" <lmr@xxxxxxxxxx> wrote:
> On Wed, Oct 28, 2009 at 1:43 PM, Michael Goldish <mgoldish@xxxxxxxxxx>
> wrote:
> > Sounds great, except it won't allow you to debug your configuration
> > using kvm_config.py. So the question now is what's more important
> --
> > the ability to debug or ease of use when running from the server.
>
> Here we have 2 use cases:
>
> 1) Users of the web interface, that (hopefully) have canned test sets
> that work reliably. Ability to debug stuff is less important on this
> scenario.
> 2) People developing tests, and in this case ability to debug config
> is very important
>
> I see the following options:
>
> 1) Document as part of the "test development guide" that, in order to
> be able to debug stuff, that all the test sets are to be written to
> the config file and then, can be parsed using kvm_config.
> 2) If we write all dictionaries generated by that particular
> configuration on files inside the job results directory, we still
> have
> debug ability for all use cases (I am starting to like this idea very
> much, as I type).
>
> So I'd then implement option 2) and refactor the control file with
> the
> test sets defined inside strings in the control file, then you can
> see
> how it looks? How about that?
Sounds fine.
- Where exactly will the test list appear?
- We should also allow printing of verbose debug output ("parsing variants
block, 9000 dicts in current context...") by passing something to the
constructor of the config object.
- We should make it clear to the user that he/she must rename the control
file (to control.lucas for example) or else it may be overwritten on the
next git-fetch or -pull.
I'm still not sure it's a great idea to make config debugging harder, so
if anyone other than Lucas who uses the KVM test is reading this, please
let us know if you ever use kvm_config.py and if you think the ability to
print the list of test dicts is important.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
