Open Stack

On Mon, Apr 03, 2017 at 04:06:53PM -0700, Clark Boylan wrote:
> Hello,
> 
> One of the major sets of issues currently affecting gate testing is
> Libvirt stability. Elastic-recheck is tracking Libvirt crashes for us
> and they happen frequently [0][1][2]. These issues appear to only affect
> Ubuntu Xenial (and not Trusty or CentOS or Fedora) and after talking in
> #openstack-nova it is clear that Libvirt isn't interested in debugging
> such an old version of Libvirt (1.3.1). And while it isn't entirely
> clear to me which exact version would be acceptable to them the Ubuntu
> Cloud Archive (UCA) does publish a much newer Libvirt (2.5.0).

If going to the libvirt upstream community for help, we'd generally want
to see the latest upstream release being used. Ideally along with willingness
to test git master if investigating a troublesome issue, but we understand
using git master is not practical for many people.

If using an old version provided by an OS distro, then we would generally
expect the OS distro maintainers to lead the investigation, and take the
responsibility for reproducing on latest upstream. Upstream libvirt simply
doesn't have bandwidth to do the OS distro maintainers job for them when
using old distro versions.

> I have pushed a change to devstack [3] to enable using UCA which pulls
> in new Libvirt and mostly seems to work. I think we should consider
> switching to UCA as this may fix our Libvirt problems and if it doesn't,
> we will be closer to a version of Libvirt that upstream should be
> willing to fix.
> 
> This isn't the most straightfoward switch as UCA has a different repo
> for each OpenStack release. libvirt-python is sensitve to the underlying
> library changing; it is backward compatible but libvirt-python built
> against older libvirt won't work against new libvirt. The result is a
> libvirt-python wheel built on our wheel mirror does not work with UCA.

I'm surprised about that - could you elaborate on what's broken for you.
The libvirt.so provides a stable public API, and the standalone python
binding only uses public APIs from libvirt.so.  IOW you should be able
to build libvirt-python against 1.3.0 and then use it against 2.5.0 with
no problems.

NB, *before* libvirt-python lived on pypi, it used some non-public
libvirt.so symbols, so was tied to the exact libvirt.so it was built
against. Assuming you're using the pypi version this should no longer
apply.

> Now its entirely possible that newer Libvirt will be worse than current
> (old) Libvirt; however, being closer to upstream should make getting
> fixes easier. Would be great if those with a better understanding of
> Libvirt could chime in on this if I am completely wrong here.

As a general rule your expectation is right - newer libvirt should
generally be better. There is always the chance of screwups, but we issue
maint releases where needed - the only question mark would be whether UCA
pulls in any maint releases. I would like to think that if such a problem
happened, openstack would be able to escalate it to a Canonical maintainer
to get a maint release / patch into UCA, since presumably any such bug
would be important to Canonical customers using OpenStack too.

> Finally it is worth noting that we will get newer packages of other
> software as well, most notably openvswitch will be version 2.6.1 instead
> of 2.5.0.

IIUC, you'd get newer QEMU/KVM too, which is arguably just as desirable
as getting newer libvirt.

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