Open Stack

On Fri, Apr 06, 2018 at 06:07:18PM +0200, Thomas Goirand wrote:
> On 04/06/2018 12:07 PM, Kashyap Chamarthy wrote:

[...]

> > Note: You don't even have to build the versions from 'Buster', which are
> > quite new.  Just the slightly more conservative libvirt 3.2.0 and QEMU
> > 2.9.0 -- only if it's possbile.
> 
> Actually, for *official* backports, it's the policy to always update to
> wwhatever is in testing until testing is frozen. 

I see.  Sure, that's fine, too (as "Queens" UCA also has it).  Whatever
is efficient and least painful from a maintenance POV.

> I could maintain an unofficial backport in stretch-stein.debian.net
> though.
>
> > That said ... I just spent comparing the release notes of libvirt 3.0.0
> > and libvirt 3.2.0[1][2].  By using libvirt 3.2.0 and QEMU 2.9.0, Debian users
> > will be spared from a lot of critical bugs (see all the list in [3]) in
> > CPU comparision area.
> > 
> > [1] https://www.redhat.com/archives/libvirt-announce/2017-April/msg00000.html
> >     -- Release of libvirt-3.2.0
> > [2] https://www.redhat.com/archives/libvirt-announce/2017-January/msg00003.html
> >     --  Release of libvirt-3.0.0
> > [3] https://www.redhat.com/archives/libvir-list/2017-February/msg01295.html
> 
> So, because of these bugs, would you already advise Nova users to use
> libvirt 3.2.0 for Queens?

FWIW, I'd suggest so, if it's not too much maintenance.  It'll just
spare you additional bug reports in that area, and the overall default
experience when dealing with CPU models would be relatively much better.
(Another way to look at it is, multiple other "conservative" long-term
stable distributions also provide libvirt 3.2.0 and QEMU 2.9.0, so that
should give you confidence.)

Again, I don't want to push too hard on this.  If that'll be messy from
a package maintainance POV for you / Debian maintainers, then we could
settle with whatever is in 'Stretch'.

Thanks for looking into it.

-- 
/kashyap