[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

From: Lucas Meneghel Rodrigues
Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU
Date: Thu, 29 Dec 2011 20:45:44 -0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

On 12/29/2011 12:38 PM, Dor Laor wrote:
 From the recent threads it looks to me that the 2 advantages of
qemu-test over kvm-autotest are:

1. python is not used within the guest

^ Just a (relatively small) subset of KVM autotest tests do require python in the guest (the ones that execute the autotest client inside the guest, virtio-console, and ksm overcommit), so if you don't want py on the guest, just execute the tests that do not require it. For example, we don't rely on any python for the Windows tests.

2. qemu-test is smaller and simpler

Except for the above 2, kvm autotest is superior. My main motivation to
merge qemu-test and kvm autotest is that I fear that qemu-test will be
the only requirement for committing stuff for qemu and developers will
be excused from their 'duty' by writing a 50 LOC shell script and assume
they done w/ testing. In addition to that, the 50 LOC will be too basic
and only provide value for basic functionality tests and kvm autotest
folks will need to rewrite all of the matching content and beyond.

Requiring people to writing tests for qemu-test is already a improvement over the current situation. It might make people more interested and engaged on test driven development, some of them might want to take the time and learn how to use and develop tests for autotest. We gotta start with something :)

Those above 2 advantages can be solve:

1. python is not used within the guest
- One option is just to use the same shell code in kvm autotest w/o
no python code and use the same kernel/initramfs.
- Another way is to use a plain linux distro w/ python and boot it
into single user test mode and potentially use a S4 guest snapshot
or external snapshot to shorten its boot time.
You'll get faster boot time and friendlier code.

Yes, slowly we are making autotest and the kvm tests faster by disabling by default some settings that make more sense to be enabled on automated test grids (drop memory caches, take a list of all packages installed on the test machine *between* tests, things like that). Hopefully it'll improve the experience of using it quite a lot.

Then, on the virt test side, we can find ways to cut the time to start the functional tests like you suggested (small, pre-installed images, snapshots, you name it). In any case, I believe that qemu-test is positive, since it lowers the barrier and gets people interested in writing tests. As long as we are careful and avoid overlapping features as much as possible, it's fine.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]