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

Re: [libvirt] [PATCH] tests: Test for nwfilter



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


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