Re: [libvirt] Drop support for old libvirt versions?
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