Re: [RFC] KVM test: Refactoring the kvm control file and the config file

[Ryan Harper <ryanh@us.ibm.com>]

* Michael Goldish <mgoldish@redhat.com> [2009-07-21 07:38]:
> 
> ----- "Lucas Meneghel Rodrigues" <lmr@redhat.com> wrote:
> 
> > Currently we have our kvm test control file and configuration file,
> > having them split like this makes it harder for users to edit it,
> > let's
> > say, using the web frontend.
> > 
> > So it might be good to merge the control file and the config file,
> > and
> > make a refactor on the control file code. Do you think this would be
> > a valid approach? Any comments are welcome.
> > 
> > Lucas
> 
> What exactly do you mean by merge? Embed the entire config file in
> the control file as a python string?
> 
> A few comments:
> 
> 1. The bulk of the config file usually doesn't need to be modified
> from the web frontend, IMO. It actually doesn't need to be modified
> very often -- once everything is defined, only minor changes are
> required.

Agreed.  In fact, I have a kvm_tests.common file that has all of the
guest and parameter definitions, and then I have separate "test" files
that are appended to the common file to create a kvm_tests.cfg for the
specific tests I want to run.

> 
> 2. Changes to the config can be made in the control file rather easily
> using kvm_config methods that are implemented but not currently used.
> Instead of the short form:
> 
> list = kvm_config.config(filename).get_list()
> 
> we can use:
> 
> cfg = kvm_config.config(filename)
> 
> # parse any one-liner like this:
> cfg.parse_string("only nightly")
> 
> # parse anything the parser understands like this:
> cfg.parse_string("""
> install:
>     steps = blah
>     foo = bar
> only qcow2.*Windows
> """)
> 
> # we can parse several times and the effect is cumulative
> cfg.parse_string("""
> variants:
>     - foo:
>         only scsi
>     - bar:
>         only WinVista.32
>         variants:
>             - 1:
>             - 2:
> """)
> 
> # we can also parse additional files:
> cfg.parse_file("windows_cdkeys.cfg")
> 
> # finally, get the resulting list
> list = cfg.get_list()
> 
> 3. We may want to consider something in between having the control and
> config completely separated (what we have today), and having them both
> in the same file. For example, we can define the test sets (nightly,
> weekly, fc8_quick, custom) in the config file, and select the test set
> (e.g. "only nightly") in the control file by convention. Alternatively
> we can omit the test sets from the config file, and just define a single
> test set (the one we'll be using) in the control file, or define several
> test sets in the control file, and select one of them.

Yeah, this models what I'm doing today; common config file, and then a
separate test selector mechanism.  I'd actually prefer to not have to
touch the control file at all since it already has a bunch of logic and
other info in it; and just be able to specify my test selector file.  

I think your above examples imply we can do this with the code today:

cfg = kvm_config.config(kvm_tests_common)
 
# parse any one-liner like this:
cfg.parse_string("only nightly")

> We can actually do both things at the same time, by defining the test
> sets in the config file, and defining a "full" test set among them (I
> think it's already there), which doesn't modify anything. If we want to
> use a standard test set from the config file, we can do "only nightly"
> in the control, and if we want to use a custom test set, we can do:
> cfg.parse_string("""
> only full
> # define the test set below (no need for variants)
> only RHEL
> only qcow2
> only autotest.dbench
> """)

Yep.

> 
> 4. It could be a good idea to make a "windows_cdkeys.cfg" file, that
> contains mainly single-line exceptions, such as:
> WinXP.32: cdkey = REPLACE_ME
> WinXP.64: cdkey = REPLACE_ME
> Win2003.32: cdkey = REPLACE_ME
> ...
> The real cdkeys should be entered by the user. Then the file will be
> parsed after kvm_tests.cfg, using the parse_file() method (in the
> control). This way the user won't have to enter the cdkeys into the
> long config file every time it gets replaced by a newer version. The
> cdkeys file won't be replaced because it's specific to the test
> environment (we'll only supply a sample like we do with kvm_tests.cfg).

Yep, I like that as well.

> 
> Maybe we can generalize this idea and call the file local_prefs.cfg,
> and decide that the file should contain any environment-specific
> changes that the user wants to make to the config. The file will
> contain mainly exceptions (single or multi-line). But I'm not sure
> there are many environment specific things other than cdkeys, so maybe
> this isn't necessary.
> 
> 
> Let me know what you think.

I think have a common kvm_tests.cfg file that is automatically loaded
along with the additional one-liner/custom test selector mechanism go a
long way to providing what Lucas was asking for.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com