Re: [Qemu-devel] [RFC] Future goals for autotest and virtualization tests

[Anthony Liguori]

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