Re: [libvirt] [PATCH v2] docs: add a page describing support guarantees for libvirt features

On Fri, Nov 17, 2017 at 07:57:23AM -0500, John Ferlan wrote: At least in the case of APIs without flags, the burden is pretty minimal, as from the hypervisor driver impls, the old API simply calls the new API with flags==0. So we just have the wire protocol & public API entries to keep around, which don't have a cost as that part is essentially write-once, touch never. We have never promised that every API works with every hypervisor, or every hypervisor version. If QEMU changes something that libvirt relies on we would try to adapt libvirt to an alternative impl with the same semantics. If that's no possible, we are already within our rights to just return an error from the API in question, as we can't magic a feature up out of thin air if it doesn't exist anymore :-) Fortunately hypervisors rarely delete features entirely. I think we have hit this problem in a few places before, but can't remember details offhand. It wasn't the end of the world though. It is a matter of pain for one project (libvirt) in maintaining the feature, vs pain for 10's or 100's of projects (the downstream apps) if we change a feature. The core premise of libvirt is that for the open source virt ecosystem as a whole, it is a net win if the libvirt team accepts the maint burden of providing back compat. This has also been key to the ability of entrprise distros like RHEL to pull in newer libvirt on a regular basis. Other projects have taken different views (GTK, and Python) are two significant ones that come to mind. The fallout seen from Gtk2 -> Gtk3 and Python2 to Python3 has been really massively painful for applications. The ListDomains/ListDefinedDomains/ListAllDomains APIs are probably the main case where we do have a burden in hypervisor drivers from old APIs, because we kept the original impls around without change. It would be possible to change ListDomains/DefinedDomains to actually call the ListAllDomains methods todo their work, which would take the burden out of the individual drivers. There would be some cost in performance of the old APIs though. I think that arbitrarily changing an API to return an error, is actually worse than deleting it entirely, because you've turned what would be a compile time incompatibility into a runtime incompatibility. I would only do that in the example you illustrate earlier, where a hypervisor removes a feature and there's no way for libvirt to continue to provide the equivalent functionality. There is a section inthe doc below that describes our policy wrt hypervisor version support. There are so many different release cycles / timeframes, and with Linux length of support varies per distros, that it is hard to define a fixed rule. So I used the fuzzy definition of saying we'll not support a hypervisor if the vendor has end of life'd it, and we reserve the right to end support sooner than end-of-life, if we decide that there are insufficient real world users to justify it. IOW, while technically RHEL-5 is supporting KVM still, the number of users of that who will also be interested in new libvirt is essentially zero, so we choose to drop it as a target. As a rough rule of thumb for KVM, I would go with a max of 2 RHEL major versions, so we could drop RHEL-6 when RHEL-8 comes out. I didn't want to write the doc in terms of RHEL though, as that's a bit biased towards one vendor. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|