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