----- "Lucas Meneghel Rodrigues" <l...@redhat.com> wrote: > On Wed, Oct 28, 2009 at 1:43 PM, Michael Goldish <mgold...@redhat.com> > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html