Re: [libvirt] [PATCH 00/44] Require QEMU 1.3.0 or newer
On Tue, 2018-04-03 at 09:29 -0400, John Ferlan wrote:
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".
I think there's a distinction to be made between what's part of
the "base system" and what's part of the virtualization stack.
The former is much harder to replace: if we want libvirt to build
at all on RHEL 6, we can't use glibc features that are not available
in RHEL 6's glibc, for example. Same goes for Python, yajl and many
more projects we build upon.
On the other hand, as long as both libvirt and QEMU can be built
and run on RHEL 6, it's perfectly reasonable for someone to take
the latest upstream version of *both* and run them on top of what's
still a supported OS.
Of course, it's still very possible to just stick with whatever
your vendor is offering: in RHEL 6's case, that would be QEMU 0.12
and libvirt 0.10.2, both of which are many years old at this point.
The only issue arises when you try to *combine* the two approaches,
and want to have the very latest libvirt drive RHEL 6's ancient QEMU
version. That's the kind of scenario that, when acknowledged, forces
us to keep around a lot of crufty code. What me and Peter (and Jano,
I guess, since he posted the series to begin with ;) are arguing is
that such a scenario is not very reasonable and we should stop
pretending it is, by keeping around support for RHEL 6 but requiring
a reasonably modern QEMU.
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.
What you're looking for is
https://libvirt.org/git/?p=libvirt-jenkins-ci.git;a=tree;f=guests/vars
where we keep track, for each of the projects built on the CentOS
CI, of the build dependencies and, for each of the OS we build on,
what package needs to be installed in order to satisfy said build
dependencies.
And yes, it was a *lot* of work to put it together. Keeping it up
to date is not that bad, though :)
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.
I don't think we want to use maint branches for that.
We should just keep doing regular releases and, once vendors have
lost interest in keeping their downstream libvirt builds updated
besides critical issues, move on - as they already have.
--
Andrea Bolognani / Red Hat / Virtualization