On Thu, 10 Jun 2010 12:44:55 +0200
Juan Quintela <quint...@redhat.com> wrote:
> Luiz Capitulino <lcapitul...@redhat.com> wrote:
> > On Wed, 9 Jun 2010 14:10:53 +0200
> > Juan Quintela <quint...@redhat.com> wrote:
> >
> >> This is a resent with what we agreed on yesterday call.
> >> Migration events would be there for 0.13 until we get proper
> >> async command support.
> >
> > Something which is not clear to me is the set of events we'd have if
> > migrate
> > was an async command.
> >
> > Ie, do we really need MIGRATION_FAILED in this case? Don't we expect to get
> > this information from the async response?
> >
>
> I am not able to define simpler semantics for this events:
Ok, I must be missing something here.
First, let's talk about how async commands work today, better yet, how they
should work in 0.14.
I see two possible interfaces (off the top of my head):
1. QMP only returns the response when the command is finished, eg:
C: { "execute": "migrate", "id": "foo" ... }
/* nothing is returned, other commands are issued, after several hours... */
S: { "return": ... "id": "foo" }
2. QMP returns a response right away just to signal that the command
has been accepted:
C: { "execute": "migrate", "id": "foo" ... }
S: { "return": {}, "id": "foo" ... }
However, the actual response is emitted as an event:
S: { "event": "ASYNC_RESPONSE", "return": ..., "id": "foo" }
That's what I have in mind, that's why I'm confused about what we're
trying to accomplish here.
> - MIGRATION_STARTED: somebody started a migration, it is emited on
> source and target, all monitors receive this event.
The client has started the migration, it knows it. Why is the event needed?
> - MIGRATION_ENDED: migration ended with sucess, all needed data is in
> target machine. Also emitted in all monitors on source and target.
>
> - MIGRATION_CANCELED: in one of the source monitors somebody typed:
> migrate_cancel. It is only emmited on the source monitors, target
> monitors will receive a MIGRATION_FAILED event.
>
> - MIGRATION_FAILED (with this error). At this point we don't have
> neither the QMP infraestructure for sending (with this error) nor
> migration infrastructure to put there anything different than -1.
Aren't all the three events above duplicating the async response?
> This event is emmited on all source and target monitors.
> - For 0.13: Event don't have a QError.
> - For 0.14: It will gain a QError.
>
> About migration becoming an async command. Really it is independent
> of what events we emit. If migration becomes async command, only
> difference is for the monitor that emitted the command, rest of
> monitors see nothing. If we want to be able to see that informantion
> in the other monitors, we need the events anyways.
Somewhere else in this discussion someone has said that we should assume
that the client talking to the source is the same one which is going to
talk to the target, in this case all the communication is done through
the source qemu instance.
