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

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

[Markus Armbruster]

"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.

>> 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.

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

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

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

[Dr. David Alan Gilbert]

* 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

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

[Paolo Bonzini]

Il 02/06/2014 15:50, Dr. David Alan Gilbert ha scritto:
> 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.

It also means we have a higher risk of getting it wrong, and having to 
do the work twice.

Paolo

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

[Dr. David Alan Gilbert]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> Il 02/06/2014 15:50, Dr. David Alan Gilbert ha scritto:
> >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.
> 
> It also means we have a higher risk of getting it wrong, and having to do
> the work twice.

That's why all this is does is provide the interface; it doesn't do anything behind
it and just allows us to wire in libvirt etc.

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

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

[Paolo Bonzini]

Il 02/06/2014 18:40, Dr. David Alan Gilbert ha scritto:
>>> > >
>>> > >So putting this in now, and getting it into libvirt means everyone has the info.
>> >
>> > It also means we have a higher risk of getting it wrong, and having to do
>> > the work twice.
> That's why all this is does is provide the interface; it doesn't do anything behind
> it and just allows us to wire in libvirt etc.

If the version-based interface turns out to be not enough, we've done 
the work for nothing.  In fact, we already know that it is not enough to 
solve 2.0->1.6 migration with -M pc-1.5.

Paolo

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

[Dr. David Alan Gilbert]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> Il 02/06/2014 18:40, Dr. David Alan Gilbert ha scritto:
> >>>> >
> >>>> >So putting this in now, and getting it into libvirt means everyone has the info.
> >>>
> >>> It also means we have a higher risk of getting it wrong, and having to do
> >>> the work twice.
> >That's why all this is does is provide the interface; it doesn't do anything behind
> >it and just allows us to wire in libvirt etc.
> 
> If the version-based interface turns out to be not enough, we've done the
> work for nothing.  In fact, we already know that it is not enough to solve
> 2.0->1.6 migration with -M pc-1.5.

Remind me, why doesn't it solve that?
(It would be a pain to implement but if this is just the pci host format
I believe it would be doable)

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

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

[Paolo Bonzini]

Il 02/06/2014 19:44, Dr. David Alan Gilbert ha scritto:
>> > If the version-based interface turns out to be not enough, we've done the
>> > work for nothing.  In fact, we already know that it is not enough to solve
>> > 2.0->1.6 migration with -M pc-1.5.
> Remind me, why doesn't it solve that?
> (It would be a pain to implement but if this is just the pci host format
> I believe it would be doable)

Sorry, it does solve 2.0->1.6 but it would not solve 1.6->2.0.

Paolo

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

[Dr. David Alan Gilbert]

* Paolo Bonzini (pbonzini@redhat.com) wrote:
> Il 02/06/2014 19:44, Dr. David Alan Gilbert ha scritto:
> >>> If the version-based interface turns out to be not enough, we've done the
> >>> work for nothing.  In fact, we already know that it is not enough to solve
> >>> 2.0->1.6 migration with -M pc-1.5.
> >Remind me, why doesn't it solve that?
> >(It would be a pain to implement but if this is just the pci host format
> >I believe it would be doable)
> 
> Sorry, it does solve 2.0->1.6 but it would not solve 1.6->2.0.

Right, I'm only intending this to solve the problem of allowing you to migrate
to an earlier broken version while not having to keep that breakage as you
migrate forward.

The easy example would be 1.6.2->1.6.1 while also allowing 1.6.2->2.0.

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