----- "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.
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.
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
""")
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).
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.
Thanks,
Michael
--
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
