Re: [Qemu-devel] [PATCH 0/3] Migrate with destination version

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Paolo Bonzini (pbonzini@redhat.com) wrote:
> [...]
> >> Version numbers open a huge compatibility can of worms (what is a version
> >> number?)
> >
> > No, a version number here is very well defined; it's the output of
> > query-version'
> > (or 'info version' for the HMP world).
> 
> Okay, make it "version numbers are a huge, well-defined compatibility
> can of worms" :)
> 
> > How you do comparisons on that, and in particular how you parse the 'package'
> > text is a different matter, however I suggest that parsing the 'package'
> > text is downstream's problem and they provide that text.
> 
> This means that a downstream has to examine and possibly adapt the
> version number conditionals when it backports anything.

I was thinking of adding a few routines for version number comparison, in the hope
that they would help cover these two problems; but that I really thought didn't
make sense until we had some feel about how they would be used.

> >> and don't solve the fundamental problem of migration receiving
> >> insufficient testing with upstream QEMU versions.
> >
> > Indeed; and it's not meant to - in no way is this an excuse for inadequate
> > testing - however, we're all human, and bugs happen, this is just providing
> > a way to get out of some of the mess afterwards.
> 
> Understand.  It's a last resort, to be used only when the alternatives
> are all even worse.

Exactly.

> If we put this in, we'll have to review all attempts to use it very
> critically: is there really, really no practical alternative?

Yep.

> Can you explain why we should put it in before we have a user?

If we have it in then we can get libvirt to use it.
If we have it all in place then if we do hit a compatibility
issue where we need to use it, then it's easy.

If we don't put it in, then if we hit this type of situation
we suddenly need to coordinate a modification of libvirt as well.

However, it gets trickier since the destination libvirt has to know to send
the version information to the source; so we can only use this trick between
versions where the libvirt on both ends knows about it; so if we suddenly hit
a compatibility issue where we need it then we'd have to update libvirt on both
sides, which is too late.

So putting this in now, and getting it into libvirt means everyone has the info.

Dave
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK