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: - MIGRATION_STARTED: somebody started a migration, it is emited on source and target, all monitors receive this event. - 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. 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. Why do we want this? It makes things like audit simpler (we already know when a machine starts/stops, knowing when it migrates is also a good idea. Same for things like the storage management examples that danp did. With events, it becomes trivial, without events, it can be done with workarounds, sending messages left, rigth and center. Spice also wanted the equivalent of this events to reconnect to the new server machine. I can't see why people have so much trouble with this events, they are of the simpler class. The only real problem that we have is what to put on the MIGRATE_FAILED event, and the problem is an infrastructure one, that we don't have neither what or how to put something useful there. At this point, management applications only want to know if migration ended with success or with failure, but they will like to know at some point what kind of failure they had. Later, Juan.