On Tue, Jul 21, 2009 at 11:05 AM, Ryan Harper<ryanh@xxxxxxxxxx> wrote:
> * 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.
Not editing the control file at all kinda subverts the original idea
of having the control as 'the' description of the test job. This is
one of the problems I was seeing with this approach. And when I mean
'refactor', I mean that the logic contained inside the control file
could be refactored to be made simpler.
That said, I don't think it is a *huge* problem right now, just
something that needs to be addressed at some point in time.
> 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.
Yes, that would be a valid approach. Thanks for sharing your ideas, Ryan.
--
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
