[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 17 Jun 2010 18:34:00 +0200
Juan Quintela <quintela@redhat.com> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > On Wed, 16 Jun 2010 21:10:04 +0200
> > Juan Quintela <quintela@redhat.com> wrote:
> >
> >> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> >> > On Tue, 15 Jun 2010 17:24:59 +0200
> >> > Juan Quintela <quintela@redhat.com> wrote:
> >> 
> >> >> >
> >> >> >  I still don't see the need for MIGRATION_STARTED, it could be useful in
> >> >> > the target but I'd like to understand the use case in more detail.
> >> >> 
> >> >> At this point, if you are doing migration with tcp, and you are putting
> >> >> the wrong port on source (no path or any other error), you get no info
> >> >> at all of what is happening.
> >> >
> >> >  Shouldn't the migrate command just the return the expected error?
> >> 
> >> No.  Think you are "having troubles".  You try to find what happens.
> >> launch things by hand.  And there is no way to know if anybody has
> >> conected to the destination machine.  Some notification that migration
> >> has started is _very_ useful.  expecially when there are
> >> networks/firewalls/... in the middle.
> >
> >  [...]
> >
> >> That is it.  But you continue telling that going to the old house and
> >> doing a info migrate is a good interface.
> >
> >  I'm sorry? When did I ever claimed such a thing?
> 
> polling is enough.  polling has to be done in source machine.

 Enough for the meantime, until we have something better to offer. The problem
here is that adding not so good stuff to a protocol is that we will have to
maintain it for a quite long time, possibly forever.

 That's why I'm being so opposed to a large set of events, a reduced set is a lot
more attractive.

> >  First point: all you describe is MIGRATION_CONNECTED, at the end of the day
> > it would do exactly what you want for MIGRATION_STARTED.
> >
> >  The second, and most important point, is that we're trying not to make
> > things worse. Adding a number of events to circumvent a bad designed
> > command and having the wrong expectations (ie. help developer debugging)
> > is a clear recipe for disaster.
> >
> >  Anyway, I think it doesn't matter anymore, as QMP is not going to be declared
> > stable for 0.13. In this case we'll have enough time to design the proper
> > interface.
> >
> >> To add insult to injury, the problem is that libvirt people are not
> >> collaborative, and expect things that can't be done, are uncooperative,
> >
> >  Again, I've never claimed that and I think you're taking this thread to
> > the wrong direction.
> 
> Ok, I stop then.

 I'm not asking you to stop arguing, just to avoid taking the non-technical
route in a bad way.

 Now, we have the following situation: MIGRATION_CONNECTED and MIGRATION_DONE
would have possibly been a good fit for 0.13 if QMP was going to be stable.

 However, that's not going to happen so the question is: is it interesting
to have those events for an unstable QMP? Do we expect any client to need it? Or
can we wait until 0.14?