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

[Anthony Liguori]

On 06/11/2010 09:30 AM, Luiz Capitulino wrote:
> On Thu, 10 Jun 2010 12:44:55 +0200
> Juan Quintela<address@hidden>  wrote:
>
>    
> > Luiz Capitulino<address@hidden>  wrote:
> >      
> > > On Wed,  9 Jun 2010 14:10:53 +0200
> > > Juan Quintela<address@hidden>  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" }
>    

This is how just about every RPC mechanism works...

>   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 quite unusual and I don't see why it would be necessary.  It adds 
quite a bit of complexity because now clients have to handle to distinct 
error conditions instead of one.

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

I think we've more or less agreed that MIGRATION_CONNECTED is really the 
event we want.

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

Yes.  Today, we should just generate a MIGRATION_DONE event and let a 
client poll for failure status.

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

MIGRATION_DONE gets deprecated for 0.14.

Regards,

Anthony Liguori