On Tue, 2018-04-03 at 12:57 +0200, Peter Krempa wrote:
On Tue, Apr 03, 2018 at 11:45:19 +0100, Daniel Berrange wrote:
> On Fri, Mar 30, 2018 at 03:15:16PM +0200, Ján Tomko wrote:
> > It's been a while since we last bumped the minimum QEMU version.
> > Let's get rid of -help parsing and bring our test suite closer
> > to real world usage by implying lots of capabilities.
>
> NACK, this is effectively dropping support for RHEL-6 without explicitly
> saying you're doing this.
Upstream libvirt does not support driving the RHEL-6 qemu anyways (at
least from the latest releases) as it diverged significantly from
upstream. Upstream will e.g. not be able to see that JSON monitor needs
to be used with that old version or that the downstream implementations
of some commands need to be used.
Using upstream libvirt on rhel6 without upstream qemu is nonsense. The
argument that you might want new features with the "stability" of the
old OS is wrong if you pull in bugs from upstream.
This makes sense to me. One of the (several) times the topic of
dropping support for older OS, one of the arguments against it was
that downstream vendors were building products on top of RHEL 6,
but at the same time needed newer QEMU / libvirt features, so they
pulled those in from upstream.
Bumping our minimum QEMU version wouldn't affect that kind of
scenario, as long as we keep making sure libvirt itself builds on
RHEL 6 - which we already do as part of the CI effort.
Honestly, who in the world absolutely needs the very last libvirt
while at the same time being stuck with QEMU < 1.3.0? However you
slice it, that doesn't sound like a remotely sane scenario.
--
Andrea Bolognani / Red Hat / Virtualization