Open Stack

FYI, the context of this is that I would like to be able to test some of the libvirt storage pool code against a live file system, as we currently test the storage pool code.  To do this, we need at least to be able to get a proper connection to a session daemon.  IMHO, since these calls aren't "expensive", so to speak, it should be fine to have them run against a real libvirt.

> So If we require libvirt-python for tests and that requires
> libvirt-bin, what's stopping us from just removing fakelibvirt since
> it's kind of useless now anyway, right?

The thing about fakelibvirt is that it allows us to operate against against a libvirt API without actually doing libvirt-y things like launching VMs.  Now, libvirt does have a "test:///default" URI that IIRC has similar functionality, so we could start to phase out fakelibvirt in favor of that.  However, there are probably still some spots where we'll want to use fakelibvirt.

Best Regards,
Solly

----- Original Message -----
> From: "Matt Riedemann" <mriedem at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Sent: Wednesday, August 20, 2014 8:37:39 PM
> Subject: Re: [openstack-dev] [nova][libvirt] Non-readonly connection to libvirt in unit tests
> 
> 
> 
> On 8/11/2014 4:42 AM, Daniel P. Berrange wrote:
> > On Mon, Aug 04, 2014 at 06:46:13PM -0400, Solly Ross wrote:
> >> Hi,
> >> I was wondering if there was a way to get a non-readonly connection
> >> to libvirt when running the unit tests
> >> on the CI.  If I call `LibvirtDriver._connect(LibvirtDriver.uri())`,
> >> it works fine locally, but the upstream
> >> CI barfs with "libvirtError: internal error Unable to locate libvirtd
> >> daemon in /usr/sbin (to override, set $LIBVIRTD_PATH to the name of the
> >> libvirtd binary)".
> >> If I try to connect by calling libvirt.open(None), it also barfs, saying
> >> I don't have permission to connect.  I could just set it to always use
> >> fakelibvirt,
> >> but it would be nice to be able to run some of the tests against a real
> >> target.  The tests in question are part of
> >> https://review.openstack.org/#/c/111459/,
> >> and involve manipulating directory-based libvirt storage pools.
> >
> > Nothing in the unit tests should rely on being able to connect to the
> > libvirt daemon, as the unit tests should still be able to pass when the
> > daemon is not running at all. We should be either using fakelibvirt or
> > mocking any libvirt APIs that need to be tested
> >
> > Regards,
> > Daniel
> >
> 
> Also, doesn't this kind of break with the test requirement on
> libvirt-python now?  Before I was on trusty and trying to install that
> it was failing because I didn't have a new enough version of libvirt-bin
> installed.  So if we require libvirt-python for tests and that requires
> libvirt-bin, what's stopping us from just removing fakelibvirt since
> it's kind of useless now anyway, right?
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>