On 03/09/2012 07:07 AM, Paolo Bonzini wrote:
Il 08/03/2012 22:24, Anthony Liguori ha scritto:
The qemu-test tests are smaller than the corresponding autotest tests.
They also do much less.
It's true that a combination of qemu-test + qtests could do 99% of the
job more simply than autotest. But the last 1% (including migration)
would require a large effort, while it would be just there in autotest.
Can you clarify here? When you say "migration", what I think you mean is that
kvm-autotest has the ability to run autotest client tests within a guest while
migration.
I do not believe (with the exception of virtio-serial) that it has the ability
to run tests like pci_hotplug while migrating.
That means libautotest would have nothing to do with the migration test in
kvm-autotest.
IOW, if we integrate qemu-test with gtest, and autotest learned how to speak the
gtest protocol, what features would not be available to gtest-based tests verses
ones written against libautotest?
Making autotest an unconditional dependency of qemu.git is a non-starter for me.
If it were as simple as "yum install py-autotest" it would not be a
problem, would it?
It if existed today, had clear value, was widely available, and had a stable
interface, it wouldn't be an insurmountable problem.
But none of those points are true right now. And right now, the most important
one is "has clear value". We really need to have a clear technical discussion
about libautotest would actually do.
AFAICT, only two things have been suggested for what it would do:
1) it replaces gtest with its own protocol (but why is this protocol better than
gtest?)
2) it adds a launching abstraction layer such that the same test can be launched
with QEMU directly and with libvirt.
But (2) is an anti-feature from my point of view. The last thing we need is yet
another layer of abstraction for launching QEMU.
Regards,
Anthony Liguori
Paolo
