On Tue, Apr 03, 2018 at 02:49:34PM +0100, Daniel P. Berrangé wrote: > 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. That sounds reasonable, I would even vote for 2 year overlap, but that would be probably way too strict so 3 year overlap is a good compromise. This would mean that we can drop support for RHEL < 7, SLES < 12 and Debian < 8. Pavel
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
