[Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release
kchamart at redhat.com
Mon Apr 9 09:58:58 UTC 2018
On Fri, Apr 06, 2018 at 12:12:31PM -0500, Matt Riedemann wrote:
> On 4/6/2018 12:07 PM, Kashyap Chamarthy wrote:
> > 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'.
> Keep in mind that Kashyap has a tendency to want the latest and greatest of
> libvirt and qemu at all times for all of those delicious bug fixes.
Keep in mind that Matt has a tendency to sometimes unfairly
over-simplify others views ;-). More seriously, c'mon Matt; I went out
of my way to spend time learning about Debian's packaging structure and
trying to get the details right by talking to folks on
#debian-backports. And as you may have seen, I marked the patch[*] as
"RFC", and repeatedly said that I'm working on an agreeable lowest
> But we also know that new code also brings new not-yet-fixed bugs.
Yep, of course.
> Keep in mind the big picture here, we're talking about bumping from
> minimum required (in Rocky) libvirt 1.3.1 to at least 3.0.0 (in Stein)
> and qemu 2.5.0 to at least 2.8.0, so I think that's already covering
> some good ground. Let's not get greedy. :)
Sure :-) Also if there's a way we can avoid bugs in the default
experience with minimal effort, we should.
Anyway, there we go: changed the patch[*] to what's in Stretch.
More information about the OpenStack-operators