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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list