On Fri, 11 Jun 2010 09:38:42 -0500 Anthony Liguori <anth...@codemonkey.ws> wrote:
> > 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... Let's go for it then. > >> - 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. Is it useful in the source or in the target? > >> - 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. [...] > MIGRATION_DONE gets deprecated for 0.14. Yeah, this removes the need for polling in 0.13, but I was wondering if it's worth it. If I'm not mistaken, libvirt does the polling when working with the text Monitor and I believe it's not a big deal to keep it until 0.14.