On Tue, 25 May 2010 13:51:01 -0500 Anthony Liguori <anth...@codemonkey.ws> wrote:
> On 05/25/2010 01:31 PM, Luiz Capitulino wrote: > > On Tue, 25 May 2010 16:21:03 +0200 > > Juan Quintela<quint...@redhat.com> wrote: > > > > > >> They are emitted when migration starts, ends, has a failure or is canceled. > >> > >> Signed-off-by: Juan Quintela<quint...@redhat.com> > >> --- > >> QMP/qmp-events.txt | 50 > >> ++++++++++++++++++++++++++++++++++++++++++++++++++ > >> monitor.c | 12 ++++++++++++ > >> monitor.h | 4 ++++ > >> 3 files changed, 66 insertions(+), 0 deletions(-) > >> > >> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt > >> index 01ec85f..93caa4d 100644 > >> --- a/QMP/qmp-events.txt > >> +++ b/QMP/qmp-events.txt > >> @@ -26,6 +26,56 @@ Example: > >> Note: If action is "stop", a STOP event will eventually follow the > >> BLOCK_IO_ERROR event. > >> > >> +MIGRATION_CANCELED > >> +------------------ > >> + > >> +Emitted when migration is canceled. This is emitted in the source. > >> > > Shouldn't this one be emitted in the destination? > > > > Destination can't distinguish a cancelled from a closed pipe. But the > idea is that a third party is talking to both source and destination so > it knows if it's cancelled the migration. Yeah, got it. > >> +Target will emit MIGRATION_FAILED (no way to differentiate a FAILED > >> +and CANCELED migration for target). > >> + > >> +Data: None > >> + > >> +Example: > >> + > >> +{ "event": "MIGRATION_CANCELED", > >> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} } > >> + > >> +MIGRATION_ENDED > >> +--------------- > >> + > >> +Emitted when migration ends (both in source and target) > >> + > >> +Data: None > >> + > >> +Example: > >> + > >> +{ "event": "MIGRATION_ENDED", > >> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} } > >> + > >> +MIGRATION_FAILED > >> +---------------- > >> + > >> +Emitted when migration fails (both is source and target). > >> + > >> +Data: None > >> + > >> +Example: > >> + > >> +{ "event": "MIGRATION_FAILED", > >> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} } > >> > > What about a MIGRATION_FINISHED event, which contains a 'success' > > key which is a bool? > > > > The only disadvantage of this is if we decide to add more information > > to the event (say, stats) then it'd get ugly. Otherwise, one event is > > enough. > > > > Anyway, the counterpart of MIGRATION_FAILED is MIGRATION_SUCCEEDED. > > > > I see MIGRATION_FAILED as being very similar to block I/O error events. > I think we'll need a very similar solution for both. It boils down to, > how do we raise asynchronous events when something fails? You mean we should have a sort of error specific events?