On 02/14/2014 08:28 PM, Chris Evich wrote:
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 :(

Ok, I reverted my PR and now it's all back to what it was previous to my changes.

https://github.com/autotest/tp-libvirt/commit/7bd6347a775948fabbd649ab48740b4e967a342a


_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel

Reply via email to