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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
