On 02/05/2014 07:19 PM, Lucas Meneghel Rodrigues wrote:
On 02/05/2014 03:07 PM, Lucas Meneghel Rodrigues wrote:
Organizing a codebase that has been developed for over 5 years
'organically' is not easy.
With the repository split work, it has become evident that having to
create 2 PRs just to add a new libvirt test is awkward at best (one
tp-libvirt PR for the test itself, another one to add stuff to
virttest.virsh and/or virttest.libvirt_xml, which nearly universally
happens). The same also happens to qemu tests, of course.
It is imperative to make efforts to split, clean and streamline the
available virtualization test APIs. Keeping things streamlined is quite
the challenge, as the sheer amount of code being pushed every day to
virt-test makes difficult to keep paying attention to where all these
functions are being thrown to. When you have 50 open PRs open, you are
not exactly picky with regards to where people decide to put code.
That's how I'm approaching the problem:
(1) - Go over the current virttest namespace, and assessing which
libraries can be transferred over existing test providers
(2) - Create the PRs to make transfer/fix references
(3) - Somehow come up with 'rules' about what belongs to test providers
-virttest -autotest.
(4) - Have API police ready to enforce the rules.
(1) and (2) are far easier than (3) and (4). We did try to have rules
before, but the project grew, the rules were written only to docstrings
of modules, and the pressure on delivering time reviews with few
reviewers made any sort of rule enforcement to fail.
This means you are welcome to help with creating rules for API placement
(3), and mechanisms to enforce such rules (4). Meanwhile, I'll carry on
with (1) and (2).
Ok, so going with (1), here's the list of APIs and my assessment of each
of them:
Update: This is worse that I could ever imagine. At this point the
libraries are a tangled mess, and a lot of dependencies that did not
show up on a 1st look came back to bite me.
utils_net depends on openvswitch
env_process depends on utils_libvirtd
utils_test base depends on libvirt_xml
That's enough to make life miserable here. I'll have to re-start the work.
So, after a while thinking, I made the simplest change that touched only
in the biggest offender, virttest.virsh, while not breaking any current
code and still letting people to create virsh tests without 2 PRs
(hopefully). You can see it here:
https://github.com/autotest/tp-libvirt/pull/12
Long story short, now libvirt tests access a 'proxy' virsh module by:
from provider import virsh
And to add new virsh functions, you just add them to
provider/virsh.py
In tp-libvirt. Of couse, at some point we need to actually move the 150
functions that are not necessary by core virt-test functionality, but we
can do it in a more calm fashion.
Let me know if you guys have any problems,
Lucas
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
