[libvirt] Drop support for old libvirt versions?

[Andrea Bolognani]

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