Open Stack

On Fri, May 15, 2015 at 11:51:22AM +0100, Daniel P. Berrange wrote:
> On Thu, May 14, 2015 at 02:23:25PM -0500, Matt Riedemann wrote:
> > The minimum required version of libvirt in the driver is 0.9.11 still [1].
> > We've been gating against 1.2.2 in Ubuntu Trusty 14.04 since Juno.
> > 
> > The libvirt distro support matrix is here: [2]
> > 
> > Can we safely assume the people aren't going to be running Libvirt compute
> > nodes on RHEL < 7.1 or Ubuntu Precise?
> 
> I don't really think so - at the very least Fedora 20 and RHEL 7.0 are still
> actively supported platforms by their vendors, which both have older libvirt
> versions (1.1.3 and 1.1.1 respectively).
> 
> I'm not sure whether SUSE team consider any of the 12.x versions to still be
> actively supported platforms or not, likewise which 13.x versions are under
> active support.
> 
> 
> > Regarding RHEL, I think this is a safe bet because in Kilo nova dropped
> > python 2.6 support and RHEL > 6 doesn't have py26 so you'd be in trouble
> > running kilo+ nova on RHEL 6.x anyway.
> 
> There are add-on repos for RHEL-6 and RHEL-7 that provide newer python
> versions so (py27, various py3x), so it is not unreasonable for people
> to consider sticking with RHEL-6 if that is what their existing deployment
> is based on. Certainly new deployments though I'd expect to be RHEL-7 based.
> 
> > There are some workarounds in the code [3] I'd like to see removed by
> > bumping the minimum required version.
> 
> Sure, its nice to remove workarounds from a cleanliness POV, but I'm generally
> pretty conservative about doing so, because in the majority of case (while it
> looks ugly) it is not really a significant burden on maintainers to keep it
> around.
> 
> This example is really just that. It certainly looks ugly, but we have the
> code there now, it is doing the job for people who have that problem and it
> isn't really having any measurable impact on our ability to maintain the
> libvirt code. Removing this code won't lessen our maintainance burden in
> any way, but it will unquestionably impact our users by removing support for
> the platform they may be currently deployed on.

BTW, the code you quote here:

   http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/host.py?id=2015.1.0#n754

is not actually working around a bug the libvirt hypervisor. It is in fact
a bug in the libvirt-python API binding. As such we don't actually need to
increase the min required libvirt to be able to remove that check. In fact
increasing the min required libvirt is the wrong thing todo, because it is
possible for someone to have the min required libvirt, but by accessing it
via an older libvirt-python which still has the bug.

So what's really needed is a dep on libvirt-python >= 1.2.0, not libvirt.

We don't express min required versions for libvirt-python in the
requirements.txt file though, since it is an optional package and we
don't have any mechanism for recording min versions for those AFAIK.

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