[libvirt] Drop support for old libvirt versions?
A while ago, we agreed to drop support for QEMU versions older than 0.12.0, with the rationale that we should focus on operating systems that are still supported by the respective vendors, eg. RHEL/CentOS 6, Ubuntu 12.04 and SLES 11. Recently, when discussing how to ensure a certain change will not break migration with libvirt <= 0.9.4, I started wondering whether we should apply the same rationale to libvirt versions as well. Here's a quick run down of relevant libvirt versions: SLES 11 → ??? RHEL 6.0 → 0.8.1 Ubuntu 12.04 → 0.9.2 RHEL 6.8 → 0.10.2 Ubuntu 12.04.5 → 0.9.8 SLES 11 SP4 → 1.2.5 One thing I'm not clear about is whether or not SUSE, Red Hat and Canonical will support old minor releases or just the latest one. If the latter, we could safely drop support for anything older than 0.9.8, which incidentally would make the discussion referenced above entirely moot ;) In any case, having a well-defined cut-off point has been very useful when dealing with QEMU, so I think having one for libvirt itself would be beneficial too. Looking forward to your thoughts on this :) -- Andrea Bolognani / Red Hat / Virtualization
On 08/12/2016 10:25 AM, Andrea Bolognani wrote:
A while ago, we agreed to drop support for QEMU versions older than 0.12.0, with the rationale that we should focus on operating systems that are still supported by the respective vendors, eg. RHEL/CentOS 6, Ubuntu 12.04 and SLES 11.
Recently, when discussing how to ensure a certain change will not break migration with libvirt <= 0.9.4, I started wondering whether we should apply the same rationale to libvirt versions as well.
Here's a quick run down of relevant libvirt versions:
SLES 11 → ???
Heh, the original SLES 11 had 0.4.6.
RHEL 6.0 → 0.8.1 Ubuntu 12.04 → 0.9.2
RHEL 6.8 → 0.10.2 Ubuntu 12.04.5 → 0.9.8 SLES 11 SP4 → 1.2.5
One thing I'm not clear about is whether or not SUSE, Red Hat and Canonical will support old minor releases or just the latest one.
For SLES 11, active maintenance is only on the latest one (1.2.5). SUSE provides long-term support for libvirt 1.0.5 in SLES 11 SP3, but bug reports are rare these days. SUSE also provides long-term support for SLES 10 SP4 (libvirt 0.3.3), but I haven't seen a bug report in years on that one! I'd be shocked if anyone was using SLES10 SP4 as a virtualization host :-). Regards, Jim
On 12.08.2016 18:25, Andrea Bolognani wrote:
<snip/>
I like the idea. I mean, the less versions we have to take care of the better. But before we go any further - what do you mean by dropping support? For instance, what I think of is when formatting migration XML we won't remove devices (like USB hubs or what is it) just because the other side is too old. Or you even mean deprecating APIs? Michal
On Sat, Aug 13, 2016 at 10:16:03AM +0200, Michal Privoznik wrote:
On 12.08.2016 18:25, Andrea Bolognani wrote:
<snip/>
I like the idea. I mean, the less versions we have to take care of the better. But before we go any further - what do you mean by dropping support? For instance, what I think of is when formatting migration XML we won't remove devices (like USB hubs or what is it) just because the other side is too old.
Or you even mean deprecating APIs?
My question exactly. What support are you talking about? Forward compatible migration support (migrating back to older libvirt versions)? I don't think that's very much supported at all. Talking about old APIs (e.g. superseded and obsoleted ones)? I don't think we can do that.
Michal
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 08/13/2016 09:24 AM, Martin Kletzander wrote:
On Sat, Aug 13, 2016 at 10:16:03AM +0200, Michal Privoznik wrote:
On 12.08.2016 18:25, Andrea Bolognani wrote:
<snip/>
I like the idea. I mean, the less versions we have to take care of the better. But before we go any further - what do you mean by dropping support? For instance, what I think of is when formatting migration XML we won't remove devices (like USB hubs or what is it) just because the other side is too old.
Or you even mean deprecating APIs?
My question exactly. What support are you talking about? Forward compatible migration support (migrating back to older libvirt versions)? I don't think that's very much supported at all. Talking about old APIs (e.g. superseded and obsoleted ones)? I don't think we can do that.
Correct. In order to remove anything from the API, we would need to increment the shared library .so version, which libvirt has promised to never do. We can only ever add to APIs (and XML). My interpretation was that Andrea is suggesting two things: 1) remove any code within libvirt that maintains compatibility when a contemporary libvirtd (or application using contemporary libvirt client library) is communicating with a version of libvirtd older than the support cutoff. This would include things like removing certain XML during migration, and (in virsh) falling back to an older deprecated API when a newer API isn't available (e.g. falling back to virDomainDefineXML() when virDomainDefineXMLFlags() isn't available). 2) stop maintaining bugfixes (including CVE fixes?) on -maint branches older than the support cutoff. I would vote +1 for doing both of these. If we do, we should document somewhere in the source and on the website exactly what is the oldest supported version, (and we may want to make a list of current versions that are still in use in distros, and a minimum "support end date" for them, then revisit it periodically).
On Sat, Aug 13, 2016 at 02:03:39PM -0400, Laine Stump wrote:
On 08/13/2016 09:24 AM, Martin Kletzander wrote:
On Sat, Aug 13, 2016 at 10:16:03AM +0200, Michal Privoznik wrote:
On 12.08.2016 18:25, Andrea Bolognani wrote:
<snip/>
I like the idea. I mean, the less versions we have to take care of the better. But before we go any further - what do you mean by dropping support? For instance, what I think of is when formatting migration XML we won't remove devices (like USB hubs or what is it) just because the other side is too old.
Or you even mean deprecating APIs?
My question exactly. What support are you talking about? Forward compatible migration support (migrating back to older libvirt versions)? I don't think that's very much supported at all. Talking about old APIs (e.g. superseded and obsoleted ones)? I don't think we can do that.
Correct. In order to remove anything from the API, we would need to increment the shared library .so version, which libvirt has promised to never do. We can only ever add to APIs (and XML).
My interpretation was that Andrea is suggesting two things:
1) remove any code within libvirt that maintains compatibility when a contemporary libvirtd (or application using contemporary libvirt client library) is communicating with a version of libvirtd older than the support cutoff. This would include things like removing certain XML during migration, and (in virsh) falling back to an older deprecated API when a newer API isn't available (e.g. falling back to virDomainDefineXML() when virDomainDefineXMLFlags() isn't available).
2) stop maintaining bugfixes (including CVE fixes?) on -maint branches older than the support cutoff.
I would vote +1 for doing both of these. If we do, we should document somewhere in the source and on the website exactly what is the oldest supported version, (and we may want to make a list of current versions that are still in use in distros, and a minimum "support end date" for them, then revisit it periodically).
That sounds very reasonable. I'd agree. The only thing I'm thinking about how to handle it a bit better, compared to the QEMU cutoff we did, is how should we handle the code cleanup and removal so that there is as little leftover as possible. I think there will be some leftovers stuck forever in both QEMU and libvirt compatibility related parts. It's just that we should somehow come up with how to shave it off as cleanly as possible. Martin
On Sat, 2016-08-13 at 21:09 +0200, Martin Kletzander wrote:
My interpretation was that Andrea is suggesting two things: 1) remove any code within libvirt that maintains compatibility when a contemporary libvirtd (or application using contemporary libvirt client library) is communicating with a version of libvirtd older than the support cutoff. This would include things like removing certain XML during migration, and (in virsh) falling back to an older deprecated API when a newer API isn't available (e.g. falling back to virDomainDefineXML() when virDomainDefineXMLFlags() isn't available). 2) stop maintaining bugfixes (including CVE fixes?) on -maint branches older than the support cutoff.
I was thinking mostly of the first point :)
I would vote +1 for doing both of these. If we do, we should document somewhere in the source and on the website exactly what is the oldest supported version, (and we may want to make a list of current versions that are still in use in distros, and a minimum "support end date" for them, then revisit it periodically). That sounds very reasonable. I'd agree. The only thing I'm thinking about how to handle it a bit better, compared to the QEMU cutoff we did, is how should we handle the code cleanup and removal so that there is as little leftover as possible. I think there will be some leftovers stuck forever in both QEMU and libvirt compatibility related parts. It's just that we should somehow come up with how to shave it off as cleanly as possible.
I'm not sure we really need to get out of our way to weed out existing compatibility code. What I care about is being able to say "we don't support that" when writing new code or reworking existing one. That said, if anyone feels like being a little more proactive I will certainly not the one to stop him! :) -- Andrea Bolognani / Red Hat / Virtualization
On Sat, Aug 13, 2016 at 02:03:39PM -0400, Laine Stump wrote:
On 08/13/2016 09:24 AM, Martin Kletzander wrote:
On Sat, Aug 13, 2016 at 10:16:03AM +0200, Michal Privoznik wrote:
On 12.08.2016 18:25, Andrea Bolognani wrote:
<snip/>
I like the idea. I mean, the less versions we have to take care of the better. But before we go any further - what do you mean by dropping support? For instance, what I think of is when formatting migration XML we won't remove devices (like USB hubs or what is it) just because the other side is too old.
Or you even mean deprecating APIs?
My question exactly. What support are you talking about? Forward compatible migration support (migrating back to older libvirt versions)? I don't think that's very much supported at all. Talking about old APIs (e.g. superseded and obsoleted ones)? I don't think we can do that.
Correct. In order to remove anything from the API, we would need to increment the shared library .so version, which libvirt has promised to never do. We can only ever add to APIs (and XML).
My interpretation was that Andrea is suggesting two things:
1) remove any code within libvirt that maintains compatibility when a contemporary libvirtd (or application using contemporary libvirt client library) is communicating with a version of libvirtd older than the support cutoff. This would include things like removing certain XML during migration, and (in virsh) falling back to an older deprecated API when a newer API isn't available (e.g. falling back to virDomainDefineXML() when virDomainDefineXMLFlags() isn't available).
I'm not in favour of dropping the virsh compat support - IMHO it is pretty beneficial and not really a significant maint burden to deal with it. The migration compat doesn't seem like a particularly significnt burden either to be honest. This is quite different from the QEMU code where our command line generator has huge amounts of complexity for dealing with different QEMU syntaxes, particularly around the -device introduction.
2) stop maintaining bugfixes (including CVE fixes?) on -maint branches older than the support cutoff.
Well we already don't officially do releases to all old maint branches, and we've never guaranteed we'll backport CVE to all old maint branches. Typically I'll backport the patches far as they'll cherry pick easily and perhaps do a few manual fixes. When the backport starts getting "hard" though I'll stop and leave the branch unfixed. 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 Mon, 2016-08-15 at 09:39 +0100, Daniel P. Berrange wrote:
My interpretation was that Andrea is suggesting two things: 1) remove any code within libvirt that maintains compatibility when a contemporary libvirtd (or application using contemporary libvirt client library) is communicating with a version of libvirtd older than the support cutoff. This would include things like removing certain XML during migration, and (in virsh) falling back to an older deprecated API when a newer API isn't available (e.g. falling back to virDomainDefineXML() when virDomainDefineXMLFlags() isn't available). I'm not in favour of dropping the virsh compat support - IMHO it is pretty beneficial and not really a significant maint burden to deal with it. The migration compat doesn't seem like a particularly significnt burden either to be honest. This is quite different from the QEMU code where our command line generator has huge amounts of complexity for dealing with different QEMU syntaxes, particularly around the -device introduction.
It's not necessarily a huge burden; that said, I believe there's some value in having a well-defined and explicit cut-off point for libvirt versions like we already have for qemu versions, especially when such a cut-off point is defined against a moving target (eg. "libvirt and qemu versions shipped in supported Linux distributions"). That's not to say we should necessarily go through the code with a fine-toothed comb and get rid of all compatibility stuff right away; however, if your changes are at odds with some code that's kinda hacky and its only purpose is to support migration to libvirt versions that are hardly relevant anymore, I think it would be better to drop the compatibility code rather than waste time updating it. -- Andrea Bolognani / Red Hat / Virtualization
On Fri, Aug 12, 2016 at 06:25:16PM +0200, Andrea Bolognani wrote:
A while ago, we agreed to drop support for QEMU versions older than 0.12.0, with the rationale that we should focus on operating systems that are still supported by the respective vendors, eg. RHEL/CentOS 6, Ubuntu 12.04 and SLES 11.
Recently, when discussing how to ensure a certain change will not break migration with libvirt <= 0.9.4, I started wondering whether we should apply the same rationale to libvirt versions as well.
Here's a quick run down of relevant libvirt versions:
SLES 11 → ??? RHEL 6.0 → 0.8.1 Ubuntu 12.04 → 0.9.2
RHEL 6.8 → 0.10.2 Ubuntu 12.04.5 → 0.9.8 SLES 11 SP4 → 1.2.5
In case that matters Debian has 0.9.12 to be supported 'til May 2018. Cheers, -- Guido
participants (7)
-
Andrea Bolognani -
Daniel P. Berrange -
Guido Günther -
Jim Fehlig -
Laine Stump -
Martin Kletzander -
Michal Privoznik