Re: [libvirt] [PATCH 00/44] Require QEMU 1.3.0 or newer

On Tue, Apr 03, 2018 at 12:57:45PM +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. The scenario wrt JSON monitor support was also the case when RHEL-6.0 first came out. It is easily addressed with a tweak to the version number check. We eventually added that RHEL-6 custom check to libvirt upstream too, but then later reverted it. Thus whether we have that tweaked version check in upstream or not, doesn't change whether we should consider the RHEL-6 vintage to be a supported target or not IMHO. > 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. Libvirt's goal has always been to enable developers to use new libvirt with previous versions of QEMU. We have *never* said that when you deploy new libvirt on a platform, you must also update QEMU. The only requirement has been that you must have the minimum declared version number, never latest upstream QEMU. It is entirely reasonable to want to use a new libvirt without updating the QEMU version, because the QEMU/KVM/kernel triple is what provides the guest OS / driver compatibility testing & thus is the most compelling part of the supported platform RHEL provides. That said we are of course not going to support RHEL-6 forever and it is reasonable to consider when the cut-off point is for the platform as a whole. Historically we have considered 2 major RHEL releases to be the target. IOW drop RHEL-6 when RHEL-8 appears. Maybe that is too long and we would be better saying we'll aim for an N year overlap of support for major RHEL releases, for a value of N that's less than the time delta between RHEL 7 & 8.