----- "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.
If you want to avoid touching the control file altogether, you can put
an 'include' statement at the end of kvm_tests.cfg:
include my_custom_file.cfg
('include' jumps to another file, parses it, and then returns to the
parent file.)
Then you can make any modifications you want in my_custom_file.cfg, and
never touch the control file or kvm_tests.cfg. Make sure the included
file exists, otherwise the parser will raise an exception.
So in total there are 3 ways to modify the config outside kvm_tests.cfg:
- cfg.parse_string() in the control file (parses any string the parser understands)
- cfg.parse_file() in the control file (parses a file)
- 'include' in kvm_tests.cfg (parses a 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")
Yes, this should certainly work, but make sure to also do
list = cfg.get_list()
when you're done parsing.
> > 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
--
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
