Open Stack

On Wed, Aug 13, 2014 at 04:24:57PM +0100, Mark McLoughlin wrote:
> On Wed, 2014-08-13 at 10:26 +0100, Daniel P. Berrange wrote:
> > On Tue, Aug 12, 2014 at 10:09:52PM +0100, Mark McLoughlin wrote:
> > > On Wed, 2014-07-30 at 15:34 -0700, Clark Boylan wrote:
> > > > On Wed, Jul 30, 2014, at 03:23 PM, Jeremy Stanley wrote:
> > > > > On 2014-07-30 13:21:10 -0700 (-0700), Joe Gordon wrote:
> > > > > > While forcing people to move to a newer version of libvirt is
> > > > > > doable on most environments, do we want to do that now? What is
> > > > > > the benefit of doing so?
> > > > > [...]
> > > > > 
> > > > > The only dog I have in this fight is that using the split-out
> > > > > libvirt-python on PyPI means we finally get to run Nova unit tests
> > > > > in virtualenvs which aren't built with system-site-packages enabled.
> > > > > It's been a long-running headache which I'd like to see eradicated
> > > > > everywhere we can. I understand though if we have to go about it
> > > > > more slowly, I'm just excited to see it finally within our grasp.
> > > > > -- 
> > > > > Jeremy Stanley
> > > > >
> > > > We aren't quite forcing people to move to newer versions. Only those
> > > > installing nova test-requirements need newer libvirt.
> > > 
> > > Yeah, I'm a bit confused about the problem here. Is it that people want
> > > to satisfy test-requirements through packages rather than using a
> > > virtualenv?
> > > 
> > > (i.e. if people just use virtualenvs for unit tests, there's no problem
> > > right?)
> > > 
> > > If so, is it possible/easy to create new, alternate packages of the
> > > libvirt python bindings (from PyPI) on their own separately from the
> > > libvirt.so and libvirtd packages?
> > 
> > The libvirt python API is (mostly) automatically generated from a
> > description of the XML that is built from the C source files. In
> > tree with have fakelibvirt which is a semi-crappy attempt to provide
> > a pure python libvirt client API with the same signature. IIUC, what
> > you are saying is that we should get a better fakelibvirt that is
> > truely identical with same API coverage /signatures as real libvirt ?
> 
> No, I'm saying that people are installing packaged versions of recent
> releases of python libraries. But they're skeptical about upgrading
> their libvirt packages. With the work done to enable libvirt be uploaded
> to PyPI, can't the two be decoupled? Can't we have packaged versions of
> the recent python bindings on PyPI that are independent of the base
> packages containing libvirt.so and libvirtd?

It is already de-coupled - the libvirt-python module up on PyPI is capable
of building against any libvirt.so C library version 0.9.11 -> $CURRENT.

The problem with Ubuntu precise is that it is C library version 0.9.6
which we can't build against because that vintage libvirt never
installed the libvirt-api.xml file that we use to auto-generated the
python code from.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|