On Mon, 2019-10-07 at 16:29 +0100, Daniel P. Berrangé wrote: > On Mon, Oct 07, 2019 at 04:58:34PM +0200, Andrea Bolognani wrote: > > It seems to me that people who want to run the latest version of > > whatever application will also use a non-obsolete operating system, > > and conversely people stuck with an old OS will rather also stick to > > the vendor-provided (and -supported) versions of the various > > components rather than installing newer ones from source. > > > > It's basically the same argument we used to justify libvirt dropping > > support for old operating systems and old QEMU versions, and I think > > it still applies when you take it one layer up the stack. > > It is the difference between the OS infrastructure layer and > the application layer. Essentially what I'm saying is that > libvirt is part of the OS infrastructure, and the libvirt > language bindings are part of the application infrastructure. > > It is valid to deploy on an old OS with vendor supplied libvirt, > while still using brand new libvirt python/Go bundled with the > application, not using the OS vendor provided version. > > The latter is in fact the recommended approach for application > developers in RHEL these days. We ship libvirt-python in RHEL-8 > built against the system python for use by virt tools we ship > like virt-install, virt-manager. From a support POV 3rd party > application developers are not supposed to use system python, > instead they must pick a python module stream. If they're lucky > their python module is the same version as system python and > they can use the system libvirt-python, but in general they > are expected to ship libvirt-python themselves as part of their > application install. I expected that to happen for languages like Rust and Go, but I thought for Python the common behavior would be to either used the packaged version (in the RHEL 8 case perhaps from a stream rather than the system one, doesn't change much) or perhaps bring in the necessary dependency with pip, not bundle it. > > If anything, the higher you go up the stack and the more developers > > are okay with having tighter coupling between their application and > > libvirt/QEMU versions, so I'd say it actually applies even more to > > them. > > I don't believe you can make such a blanket assertion about tight > coupling. I've seen both from apps developing against a very > specific min libvirt version only, vs apps developing against a > range of libvirt versions. I don't know. The latest version of oVirt requires RHEL 7.7, virt-manager is Python 3 only these days so it would be quite a pain to get it running on RHEL 6, if at all possible... The libvirt support matrix is fairly reasonable IMHO, and if you're stuck with a base OS which is outside of it I think your best bet is to stick with older versions of everything else as well. At some point, even applications that try to support arbitrarily old operating systems will end up in a situation where they're not actually testing on them (we have no CI test for libvirt-python or libvirt-go on CentOS 6, for example) and issues will either be ignored or a massive pain for developers to address. With all that said, I don't actually do any work on bindings so my own take only matters so much :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
