[libvirt] Dropping RHEL-6/CentOS-6 support
Dear list, I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive. I've proposed a patch for that [1] but honestly, neither am I - like Peter - very fond of this approach. We should not try to fix a good code because of some spurious warnings. Moreover if they happen on a system that is considered stable and thus nobody should run recent libvirt on it. In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now. I'm starting this thread so that the decision and discussion is clear and not buried under discussion to the patch. If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2]. Michal 1: https://www.redhat.com/archives/libvir-list/2016-February/msg00407.html 2: https://ci.centos.org/view/libvirt-project/job/libvirt-daemon-build/systems=...
On Tue, 2016-02-09 at 12:07 +0100, Michal Privoznik wrote:
Dear list, I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive. I've proposed a patch for that [1] but honestly, neither am I - like Peter - very fond of this approach. We should not try to fix a good code because of some spurious warnings. Moreover if they happen on a system that is considered stable and thus nobody should run recent libvirt on it. In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now. I'm starting this thread so that the decision and discussion is clear and not buried under discussion to the patch. If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].
My two Czech crowns: as far as upstream development goes, we should really only focus on supporting current OSs (eg. RHEL 7, Debian 8, Ubuntu 14.04, FreeBSD 10.2). Older OSs will be sticking to an old version of libvirt anyway, and the respective vendors will take care of backporting security fixes. This transitively applies to QEMU as well - once we drop support for CentOS 6 we should also drop support for any QEMU version that doesn't support CentOS 6. Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team
On Tue, Feb 09, 2016 at 13:24:16 +0100, Andrea Bolognani wrote:
On Tue, 2016-02-09 at 12:07 +0100, Michal Privoznik wrote:
Dear list, I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive. I've proposed a patch for that [1] but honestly, neither am I - like Peter - very fond of this approach. We should not try to fix a good code because of some spurious warnings. Moreover if they happen on a system that is considered stable and thus nobody should run recent libvirt on it. In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now. I'm starting this thread so that the decision and discussion is clear and not buried under discussion to the patch. If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].
My two Czech crowns: as far as upstream development goes, we should really only focus on supporting current OSs (eg. RHEL 7, Debian 8, Ubuntu 14.04, FreeBSD 10.2).
Older OSs will be sticking to an old version of libvirt anyway, and the respective vendors will take care of backporting security fixes.
This transitively applies to QEMU as well - once we drop support for CentOS 6 we should also drop support for any QEMU version that doesn't support CentOS 6.
TO be honest, I would be thrilled to see any support for QEMU < 1.2.0 going away, since we force QMP probing on anything newer and we could just drop all -help parsing and most of HMP support (except for a few commands which don't have QMP equivalents). QEMU 1.2.0 is tag v1.2.0 Tagger: Anthony Liguori <aliguori@us.ibm.com> TaggerDate: Wed Sep 5 07:50:34 2012 -0500 which means 3.5 years ago. Jirka
On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote:
Dear list,
I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive. I've proposed a patch for that [1] but honestly, neither am I - like Peter - very fond of this approach. We should not try to fix a good code because of some spurious warnings. Moreover if they happen on a system that is considered stable and thus nobody should run recent libvirt on it.
In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now.
I'm starting this thread so that the decision and discussion is clear and not buried under discussion to the patch.
If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].
IMHO it is well premature to stop caring about RHEL-6. We only just dropped support for RHEL-5, but RHEL-6 is very much still a widely used platform and will continue to be so for a good while yet. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 09.02.2016 13:52, Daniel P. Berrange wrote:
On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote:
Dear list,
I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive. I've proposed a patch for that [1] but honestly, neither am I - like Peter - very fond of this approach. We should not try to fix a good code because of some spurious warnings. Moreover if they happen on a system that is considered stable and thus nobody should run recent libvirt on it.
In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now.
I'm starting this thread so that the decision and discussion is clear and not buried under discussion to the patch.
If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].
IMHO it is well premature to stop caring about RHEL-6. We only just dropped support for RHEL-5, but RHEL-6 is very much still a widely used platform and will continue to be so for a good while yet.
Sure, but I'm not talking about downstream support rather than upstream one. Or are you saying that nor upstream should drop RHEL-6? Michal
On Tue, Feb 09, 2016 at 01:56:19PM +0100, Michal Privoznik wrote:
On 09.02.2016 13:52, Daniel P. Berrange wrote:
On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote:
Dear list,
I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive. I've proposed a patch for that [1] but honestly, neither am I - like Peter - very fond of this approach. We should not try to fix a good code because of some spurious warnings. Moreover if they happen on a system that is considered stable and thus nobody should run recent libvirt on it.
In RHEL-6/CentOS-6 there's libvirt-0.10.2 which is 3.5 years old now.
I'm starting this thread so that the decision and discussion is clear and not buried under discussion to the patch.
If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].
IMHO it is well premature to stop caring about RHEL-6. We only just dropped support for RHEL-5, but RHEL-6 is very much still a widely used platform and will continue to be so for a good while yet.
Sure, but I'm not talking about downstream support rather than upstream one. Or are you saying that nor upstream should drop RHEL-6?
I'm talking about upstream too. Libvirt is *not* about only supporting the latest cutting edge distros. We aim to support a broad range of distros that are currently widely in use. RHEL-6 most certainly falls under that umbrella, and upstream libvirt must *not* drop it as a targetted platform. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Tue, Feb 09, 2016 at 12:59:45 +0000, Daniel Berrange wrote:
On Tue, Feb 09, 2016 at 01:56:19PM +0100, Michal Privoznik wrote:
On 09.02.2016 13:52, Daniel P. Berrange wrote:
On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote:
...
IMHO it is well premature to stop caring about RHEL-6. We only just dropped support for RHEL-5, but RHEL-6 is very much still a widely used platform and will continue to be so for a good while yet.
Sure, but I'm not talking about downstream support rather than upstream one. Or are you saying that nor upstream should drop RHEL-6?
I'm talking about upstream too. Libvirt is *not* about only supporting the latest cutting edge distros. We aim to support a broad range of distros that are currently widely in use. RHEL-6 most certainly falls under that umbrella, and upstream libvirt must *not* drop it as a targetted platform.
The qemu in rhel6 has diverged so much from it's original code base that libvirt is carrying hacks to make it work: commit ff88cd590572277f10ecee4ebb1174d9b70fc0d7 Author: Eric Blake <eblake@redhat.com> Date: Wed Jan 25 21:33:21 2012 -0700 qemu: support qmp on RHEL/CentOS qemu I'm getting tired of remembering to backport RHEL-specific patches when building upstream libvirt on RHEL 6.x or CentOS. All the affected versions of RHEL qemu-kvm have backported enough patches to a) make JSON useful, and b) modify the -help text to mention libvirt as the preferred interface; which means this string in the help output is a reliable indicator that we can outsmart a strict version check, even when upstream qemu 0.12 lacked the needed features. This code looks specifically for the string "libvirt" which was added by the downstream version. The upstream libvirt doesn't carry a few downstream patches that make certain features work though. With the above code we are able to run with the qemu, but I'd not really want to call it that we support it. We merely put it on life support so that it works. Additionally you don't really gain much with just using new libvirt, and when you want to compile new qemu you might as well as use a completely new system as well. Using it on Centos6 would not really add any benefit in this regard. The above is to point out that users of Centos 6 usually won't compile libvirt and qemu from sources since they want to enjoy benefits of a stable platform with tested software. Sticking upstream versions on top of that defies the purpose. (I will not complain any more though. I just wanted to point this out.) Peter
On Tue, Feb 09, 2016 at 03:15:31PM +0100, Peter Krempa wrote:
On Tue, Feb 09, 2016 at 12:59:45 +0000, Daniel Berrange wrote:
On Tue, Feb 09, 2016 at 01:56:19PM +0100, Michal Privoznik wrote:
On 09.02.2016 13:52, Daniel P. Berrange wrote:
On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote:
...
IMHO it is well premature to stop caring about RHEL-6. We only just dropped support for RHEL-5, but RHEL-6 is very much still a widely used platform and will continue to be so for a good while yet.
Sure, but I'm not talking about downstream support rather than upstream one. Or are you saying that nor upstream should drop RHEL-6?
I'm talking about upstream too. Libvirt is *not* about only supporting the latest cutting edge distros. We aim to support a broad range of distros that are currently widely in use. RHEL-6 most certainly falls under that umbrella, and upstream libvirt must *not* drop it as a targetted platform.
The qemu in rhel6 has diverged so much from it's original code base that libvirt is carrying hacks to make it work:
commit ff88cd590572277f10ecee4ebb1174d9b70fc0d7 Author: Eric Blake <eblake@redhat.com> Date: Wed Jan 25 21:33:21 2012 -0700
qemu: support qmp on RHEL/CentOS qemu
I'm getting tired of remembering to backport RHEL-specific patches when building upstream libvirt on RHEL 6.x or CentOS. All the affected versions of RHEL qemu-kvm have backported enough patches to a) make JSON useful, and b) modify the -help text to mention libvirt as the preferred interface; which means this string in the help output is a reliable indicator that we can outsmart a strict version check, even when upstream qemu 0.12 lacked the needed features.
This code looks specifically for the string "libvirt" which was added by the downstream version. The upstream libvirt doesn't carry a few downstream patches that make certain features work though.
With the above code we are able to run with the qemu, but I'd not really want to call it that we support it. We merely put it on life support so that it works.
Additionally you don't really gain much with just using new libvirt, and when you want to compile new qemu you might as well as use a completely new system as well. Using it on Centos6 would not really add any benefit in this regard.
The above is to point out that users of Centos 6 usually won't compile libvirt and qemu from sources since they want to enjoy benefits of a stable platform with tested software. Sticking upstream versions on top of that defies the purpose.
NB, RHEL is not the only distro we target - when I say we should target RHEL-6 as the oldest platform, I use that mostly as an example of the approximate vintage. I would consider any still supported Debian version that is the same age as RHEL-6 to be a valid platform too, likeise for Ubuntu LTS releases or SLES. At least some of those will using fairly vanilla QEMU version without feature backports. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Tue, 2016-02-09 at 14:18 +0000, Daniel P. Berrange wrote:
The above is to point out that users of Centos 6 usually won't compile libvirt and qemu from sources since they want to enjoy benefits of a stable platform with tested software. Sticking upstream versions on top of that defies the purpose. NB, RHEL is not the only distro we target - when I say we should target RHEL-6 as the oldest platform, I use that mostly as an example of the approximate vintage. I would consider any still supported Debian version that is the same age as RHEL-6 to be a valid platform too, likeise for Ubuntu LTS releases or SLES. At least some of those will using fairly vanilla QEMU version without feature backports.
Do you mean SLES 11, RHEL 6 or Ubuntu 12.04 are likely to get the latest upstream libvirt release as a vendor update? I tend to agree with Peter when he says that people stick with older versions of software because they have a working setup and don't want to risk it breaking, and replacing vendor-provided system components with manually compiled upstream releases kinda goes in the opposite direction :) I would definitely never have risked anything like that in my previous life as a system administrator. And of course we want to support way more than just RHEL and related distros: this is about making the support shallower, not narrower :) Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team
On Tue, Feb 09, 2016 at 04:19:48PM +0100, Andrea Bolognani wrote:
On Tue, 2016-02-09 at 14:18 +0000, Daniel P. Berrange wrote:
The above is to point out that users of Centos 6 usually won't compile libvirt and qemu from sources since they want to enjoy benefits of a stable platform with tested software. Sticking upstream versions on top of that defies the purpose. NB, RHEL is not the only distro we target - when I say we should target RHEL-6 as the oldest platform, I use that mostly as an example of the approximate vintage. I would consider any still supported Debian version that is the same age as RHEL-6 to be a valid platform too, likeise for Ubuntu LTS releases or SLES. At least some of those will using fairly vanilla QEMU version without feature backports.
Do you mean SLES 11, RHEL 6 or Ubuntu 12.04 are likely to get the latest upstream libvirt release as a vendor update?
I'm not saying the vendors are going to rebase, just that we aim to enable that should they wish to. They are valid targets we aim to build for, regardless of what the OS vendors chooses todo. Users or other downstream vendors have the option to build newer libvirt / QEMU as they wish.
I tend to agree with Peter when he says that people stick with older versions of software because they have a working setup and don't want to risk it breaking, and replacing vendor-provided system components with manually compiled upstream releases kinda goes in the opposite direction :) I would definitely never have risked anything like that in my previous life as a system administrator.
For OpenStack, users are indeed updating core bits of the base OS to newer versions. It is also not neccessarily the users who are supplying the newer versions. For example, a vendor supplying software that extends RHEL, may choose to replace some bits of the core OS & support them. For example, Red Hat actually do this with their OpenStack product, where we have shipped newer versions of qemu + libvirt than were actually present in the base RHEL we deplkoyed openstack on. I know other OpenStack vendors do similarly, particularly with Ubuntu LTS releases there is an add-on cloud-archive repository providing newer versions of libvirt and QEMU. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Tue, 2016-02-09 at 15:24 +0000, Daniel P. Berrange wrote:
I tend to agree with Peter when he says that people stick with older versions of software because they have a working setup and don't want to risk it breaking, and replacing vendor-provided system components with manually compiled upstream releases kinda goes in the opposite direction :) I would definitely never have risked anything like that in my previous life as a system administrator. For OpenStack, users are indeed updating core bits of the base OS to newer versions. It is also not neccessarily the users who are supplying the newer versions. For example, a vendor supplying software that extends RHEL, may choose to replace some bits of the core OS & support them. For example, Red Hat actually do this with their OpenStack product, where we have shipped newer versions of qemu + libvirt than were actually present in the base RHEL we deplkoyed openstack on. I know other OpenStack vendors do similarly, particularly with Ubuntu LTS releases there is an add-on cloud-archive repository providing newer versions of libvirt and QEMU.
I was not aware this was common practice, and I stand corrected. Still I'm left wondering what constraints could cause such a downstream vendor, whose software apparently requires very recent version of QEMU and libvirt in order to work, to base its product on eg. Ubuntu 12.04 instead of 14.04... Thank you for taking the time to engage in this discussion, it's been quite informative :) Cheers. -- Andrea Bolognani Software Engineer - Virtualization Team
On Tue, Feb 09, 2016 at 12:07:43PM +0100, Michal Privoznik wrote:
Dear list,
I've noticed a failed build on CentOS-6 after some commits. Problem was that old gcc is not wise enough and produces a false positive.
Actually, gcc is doing exactly what we told it todo. We include -Wmaybe-uninitialized in the warning flags, which tells gcc to report warnings for uninitialized variables even if it is not entirely sure it is correct.
If we happen to stop caring we probably should stop our CentOS-6 build in jenkins too [2].
2: https://ci.centos.org/view/libvirt-project/job/libvirt-daemon-build/systems=...
The warning message shown here is actually slightly mis-leading "domain_conf.c:21475: error: 'priority' may be used uninitialized in this function [-Wuninitialized]" Notice that the message string says "may be used", not "is used". This indicates that gcc was unsure about the situation, but reported it anyway. The '[-Wuninitialized]' suffix is a horribly misleading bug in gcc 4.x - it should be saying '[-Wmaybe-uninitialized]' but that version of gcc didn't distinguish the two options when reporting the warning message :-( So a valid fix arguably could be to remove use of -Wmaybe-uninitialized flag, and only rely on -Wuninitialized where gcc is 100% certain. Personally though, I'm in favour of keeping -Wmaybe-uninitialized since some of the things reported by that will be genuine bugs, and it is easy enough for us to silence the false positives by simply initializing the variables when needed. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (5)
-
Andrea Bolognani -
Daniel P. Berrange -
Jiri Denemark -
Michal Privoznik -
Peter Krempa