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

[Cleber Rosa <crosa@redhat.com>]

On 03/09/2012 09:42 AM, Anthony Liguori wrote:
> On 03/09/2012 06:40 AM, Cleber Rosa wrote:
>> On 03/09/2012 09:04 AM, Anthony Liguori wrote:
>>> On 03/09/2012 05:20 AM, Cleber Rosa wrote:
>>>>>> You're comparing developer-level tests with the existent QA-level
>>>>>> tests (much more complex).
>>>>>
>>>>> Let's be specific then. Look at device-add.sh in qemu-test. It's 
>>>>> 71LOC.
>>>>> pci_hotplug.py in autotest is 204LOC.
>>>>
>>>> pci_hotplug.py does much more than device-add.sh:
>>>>
>>>> * tests both pci_add and device_add commands
>>>> * checks the monitor syntax for adding a new drive, that is, it 
>>>> works on HEAD
>>>> and on other versions (such as the ones in some RHEL releases);
>>>> * tests both nic and block hotplug
>>>> * for block, tests with both virtio and scsi
>>>> * also does device removal, both for pci_add and device_add syntaxes
>>>
>>> Ok, but clearly, there's no magic in autotest that makes this 
>>> sufficiently
>>> easier. It's just a matter of:
>>>
>>> cmd=`named_choose command device_add pci_add`
>>>
>>> if test $cmd = "device_add"; then
>>> qmp device_add --driver=virtio-blk-pci --drive=hd0
>>> else
>>> hmp pci_add auto virtio-blk-pci,drive=hd0
>>> fi
>>>
>>> It's not there today because pci_add is deprecated. There assertion 
>>> was that
>>> autotest makes it easier to write tests. How does it make it easier 
>>> to write
>>> pci_hotplug?
>>>
>>
>> Sure. I agree that it's fair from QEMU's PoV alone to forget about 
>> legacy things
>> such as pci_add.
>>
>> On this particular example, the one thing that strikes me the most is 
>> that
>> (kvm-)autotest allows either a very static test run (as device_add.sh 
>> does), or
>> a very configurable test run (as pci_hotplug.py does and QE needs).
>
> With named_choose and profiles, you can actually configure it very 
> specifically.  Most of the tests are not using named_choose right now, 
> but it's easy enough to change that.

And then the two code bases will end up having even more similar 
features, similar complexity, etc.

>
> Regards,
>
> Anthony Liguori