On 02/15/2014 01:27 PM, Lucas Meneghel Rodrigues wrote:
> Ok, I reverted my PR and now it's all back to what it was previous to my
> changes.
oh okay great, thanks. I wasn't sure if something else was tied to this
or not. I've been having trouble keeping up with changes since I've
been 'away' on a temporary project. I'm hoping to get back on track and
help out starting...
now!
(Actually this weekend) I had some insight smack me in the face:
Nearly all the virt testing revolves around env_process using Env to
cough-up some BaseVM subclass (i.e. one of the VM classes). However,
the code underlying the VM class exists at a higher-level than Env.
Since nearly all other higher-level code hangs off the VM classes, a lot
of stuff in virttest quickly goes into a
swirling-spaghetti-cloud-of--dependency-doom:
Level class depends on
--------- --------------------------- -------------------------------
0 env_process functions Env
1 Env {libvirt,qemu}_vm.VM.create()
2 {libvirt, qemu}_vm.VM Env
3 <tp-dir>/whatever {libvirt, qemu}_vm.VM
The only way to remain within the desired organizational constraints (no
virttest code calling up into tp-dirs), is to break lower-level
dependencies on higher-level code. IMHO, between level 2 and 3 (above)
the code is fairly unidirectional. Ignoring (for now) the test-runner,
it's clear how low env_process is to the autotest entry point:
autotest
{tp-dir}/control
utils_misc.run_tests(parser, job)
job.run_test_detail("virt"...)
virt.virt.execute(...)
virt.virt.foo -> env_process(...)
{tp-dir} test code...
To untangle levels 0 and 1, the code above virt.virt must inform the
subsequent layers about the proper classes to use. As soon as execution
goes past the virt.virt methods, the test-provider specifics become
abstracted by the base-classes.
Since the test-runner pseudo-mocks <autotest + control + run_tests()>
the practical fix-point is in run_tests and the test runner. Both of
them are able to determine the super-classes required, and therefor are
able to pass those references down (where their base-class interface can
be used).
--
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
