On 12/27/2011 02:40 PM, Anthony Liguori wrote:
On 12/27/2011 09:58 AM, Avi Kivity wrote:
On 12/27/2011 05:22 PM, Anthony Liguori wrote:
The infrastructure assumes that you have a full OS available in the
guest. The tests are written in Python and make a variety of
assumptions. To my knowledge, it's not very practical to build a
busybox environment with Python embedded in it.
You could move whatever infrastructure qemu-test uses to kvm-autotest,
at which point kvm-autotest will know everything qemu-test knows. But
there's zero reason to do that, autotest is designed to drive external
tests and in fact most of the tests it supports are not in the autotest
repository.
Yes. I think having a qemu-test driver for kvm-autotest that knows
enough to invoke the qemu-tests and integrate the results in autotest
results reporting is the right thing to do.
I am happy with that too.
There's a slight inaccuracy when you've mentioned that KVM autotest
mandates guest OS installs to perform tests. It's possible to use
pre-installed guest images, making the time of execution of a test job
shorter.
But anyway, your reasoning is sound. Considering that's not a lot of
code overlap between the 2 infrastructures, as long as we can make them
interact well, all is good. Plus, the way qemu-test is structured
integrates well with the workflow most qemu developers are used to. In
my point of view, it's a win-win situation, as I expect more developers
to invest some time writing test automation.
Ideally it would be nice to have more people contributing tests to both
qemu-test *and* kvm autotest, no doubt, but this is something we (kvm
autotest team) still have to figure how to accomplish.