* Michael Goldish <mgoldish@xxxxxxxxxx> [2009-07-21 07:38]:
>
> ----- "Lucas Meneghel Rodrigues" <lmr@xxxxxxxxxx> 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@xxxxxxxxxx
--
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
