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 :|