On Thu, Apr 05, 2018 at 06:11:26PM -0500, Matt Riedemann wrote:
> On 4/5/2018 3:32 PM, Thomas Goirand wrote:
> > If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0
> > is fine, please choose 3.0.0 as minimum.
> > If you don't absolutely need new features from qemu 2.9.0 and 2.8.0 is
> > fine, please choose 2.8.0 as minimum.
> > If you don't absolutely need new features from libguestfs 1.36 and 1.34
> > is fine, please choose 1.34 as minimum.
> New features in the libvirt driver which depend on minimum versions of
> libvirt/qemu/libguestfs (or arch for that matter) are always conditional, so
> I think it's reasonable to go with the lower bound for Debian. We can still
> support the features for the newer versions if you're running a system with
> those versions, but not penalize people with slightly older versions if not.
Yep, we can trivially set the lower bound to versions in 'Stretch'. The
intention was never to "penalize" distributions w/ older versions. I
was just checking if Debian 'Stretch' users can be spared from the
myriad of CPU-modelling related issues (see my other reply for
specifics) that are all fixed with 3.2.0 (and QMEU 2.9.0) by default --
without spending inordinate amounts of time and messy backporting
procedures. Since rest of all the other stable distributions are using
I'll wait a day to hear from Zigo, then I'll just rewrite the patch[*] to
use what's currently in 'Stretch'.
OpenStack Development Mailing List (not for usage questions)