On 02/14/2014 12:44 PM, Lucas Meneghel Rodrigues wrote: > It may not be pretty, but it was the least intrusive yet functional > fix
Least intrusive and functional for what, tp-qemu? > As long as tests use only provider.virsh, that is fine. Right, that's exactly the problem. The tests can't reliably depend on any virsh interface it's now ambiguous if we ever touch providers.virsh e.g. 1) Something contains virttest.Virsh() instances 2) Something else contains providers.Virsh() instance What happens when virttest or test code expects #1 but receives #2? > provider.virsh works one way, and it is supposed to be used by > tests. virttest.virsh should only be used by other virttest internal > modules. It's easy to say "should". The reality is, now we allow multiple circular dependencies all named "virsh" :S It's especially a problem since there's no CI happening for tp-libvirt/master (not casting blame). Couldn't this aspect have just been left as it was (warts and all), imperfect but usable? > Now, I'm sure we can make something a lot better now. Let's do this. I know you've spent a lot of time on this, but I'm really starting to feel that libvirt is being treated as a second-class citizen. We'd have testing to accomplish and deadlines approaching for new tests. However, contributions from the greater libvirt virt-test community are completely dependent on a small number of people solving a MORE difficult problem than existed a few weeks ago :( Anyway, enough complaining...I'll just re-iterate that my experience is, it's a lot less work in the long-run to address the [circular] minority entries, than re-define all the common cases. Should we start with a dependency graph of virttest, try and organize that to see which edges we can eliminate by moving nodes around? Another approach could be to list what categories and complexity levels we want to exist (and where), setup _new_ non-clashing names, cut-paste code/classes there and fixup references as we go. In any case, resolving this is going to be more about 95% inspiration and 5% perspiration. What other ideas are there? -- 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
