On 04/03/2018 10:04 AM, Daniel P. Berrangé wrote: > On Tue, Apr 03, 2018 at 09:29:01AM -0400, John Ferlan wrote: >> >> >> On 04/03/2018 07:23 AM, Andrea Bolognani wrote: >>> 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. >>> >> >> Between this and Martin's recent posting: >> >> https://www.redhat.com/archives/libvir-list/2018-April/msg00112.html >> >> Maybe we need to formulate some sort of "annual processing" to declare >> minimal version support and declare certain non-maintained drivers to be >> dead. I believe it becomes harder and harder to support a policy of must >> keep support for some sort of "older distro" as time goes on. Tools we >> use or rely on don't seem to have this same policy. Considering the >> recent python-2 to python-3 adjustments and what seems to be progressing >> towards a debate about JSON or yajl parse/formatting support - it seems >> upstream libvirt gets caught in the middle of a many "hard places". >> >> At least we have some sort of CI environment that tells us when we've >> violated some old version or a distro that some developer didn't >> consider/use. Of course, by moving the cheese from upstream to the CI >> environment - that essentially "moves" the problem of keeping older >> version support on the CI environment rather than the upstream >> development environment. All the dependency requirements are (at least >> to me) mind boggling to try to keep track of. Not sure we document them >> anywhere either. >> >> While perhaps not thought of completely in that manner, perhaps the >> *-maint branches should become "the" mechanism for support of older or >> more stable supported code. Probably means we need to do a better job at >> making sure *-maint branches always get created and of course document >> perhaps what "version adjustments" or "dependency changes" occurred for >> any particular *-maint branch. Additionally, as part of the review >> process consider whether or not a patch [series] should be back ported >> into those type branches. That leaves upstream to be relatively fresh or >> at least fresh to some period of time chosen. >> >> So, where does one start the draw the line for QEMU considering the >> following list of versions and release dates? Realistically speaking >> how long can or should upstream libvirt be expected to keep some really >> old QEMU version as minimum? Especially as it gets to be more and more >> painful to support newer versions that are coming out in 4 month cycles now. >> >> Looking at git history and considering adjustments to the VERSION file >> in the QEMU tree, I get: > > IMHO targetting QEMU specifically is wrong, because the same question comes > up repeatedly for every piece of 3rd party software we depend on. eg it makes > no sense to drop support for QEMU in RHEL-6, but then keep support for yajl > library due to jansson being missing in RHEL-6. We need to consider host > OS platforms as targets, and having decided which host OS we want, that in > turn trivially tells us when we can raise min version of *any* software > package we use. > Right - but beyond depending on you to know the history, culling some spec file for dependencies, or trying to read/understand the mappings.yaml file in the CI system, it sure would be nice to have in some sort of tabular form what we depend on, when we first started depending on it, when we "discovered" that something new was replacing it, etc. Personally there's way too many variables and considerations to keep track of in my head in order to make reasonable conclusions! I understand QEMU is just but one variable in the complex equation. Listing QEMU was just an example for this series based on the 8 years since 0.12 which is the minimum we support now vs. 5 years since 1.3 which is where this series was headed. Using the 2-3 years you responded in other threads would bring us to QEMU 2.2 or even 2.5. In the long run, I think this becomes more about being proactive than reactive. What will be "the policy" going forward. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
