On Tue, May 11, 2010 at 10:02:01PM +0200, Jim Meyering wrote:
Eric Blake wrote:
> On 05/07/2010 03:39 PM, Stefan Berger wrote:
>> This is a repost of a previously posted patch.
>>
>> Attached is a test for automatic testing of of the nwfilter rules as the
>> are instantiated in form of ebtables, iptables and ip6tables rules on
>> running VMs.
>>
>> The test automatically starts libvirtd from the build directory unless
>> it finds libvirtd running.
This is an implied race.
All it takes is a parallel "make check" and two libvirtd-starting
tests started at approximately the same time.
But that's minor.
>> My hope is that one won't notice this. It
>> uses virsh from the build directory to create two dummy VMs with random
>> name suffixes. The VMs don't boot any OS but just stop in the BIOS. This
>> is enough to run the nwfilter tests. Afterwards the nwfilter of the one
>> VM are continuously modified and the instantiation is checked. The
>> instantiation of rules of the 2nd VM are also continously checked to
>> verify that the modifications on the 1st VM has had no effect on the
>> instantiated rules of the 2nd VM.
>
> I'm still a bit wary of this patch. Is this something that can be done
> with 'virsh -c test:///default' can do? Or can we at least copy how
> daemon-conf runs an instance of libvirtd pointing to an independent pid
> and config file, whether or not the system libvirtd is running?
>
> Or should we be trying to do this as part of libvirt-tck instead?
I really like the idea of being able to test functionality like this
via a quick "make check", and using code in the same repository.
I really do not think we should be running tests that alter a machines
iptables rules as part of 'make check'. This kind of host level change
is simply not something that people expect & the consequences of a bug
here are just too bad.
However, a test that's skipped whenever it detects a running
libvirtd is less valuable than one that runs unconditionally,
so libvirt-tck is probably the ideal destination.
It is critically important to have an easily accessible "make check"-
like process that can be used to exercise more of libvirt.
I hope libvirt-tck will soon fit the bill.
It already fits that bill & is catching & preventing significant bugs in
QEMU. It has been invaluable in porting libvirt to the new QEMU JSON
interface for command & control - it wouldn't have been practical without
it in fact.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|