Open Stack

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?

(Or I could be completely misunderstanding the issue people are seeing)

Mark.