[v3,3/5] QMP: Introduce MIGRATION events

They are emitted when migration starts, ends, has a failure or is canceled.

Signed-off-by: Juan Quintela <quintela@redhat.com>
---
 QMP/qmp-events.txt |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 monitor.c          |   12 ++++++++++++
 monitor.h          |    4 ++++
 3 files changed, 68 insertions(+), 0 deletions(-)

On Wed,  9 Jun 2010 14:10:56 +0200
Juan Quintela <quintela@redhat.com> wrote:

> They are emitted when migration starts, ends, has a failure or is canceled.
> 
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
>  QMP/qmp-events.txt |   52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  monitor.c          |   12 ++++++++++++
>  monitor.h          |    4 ++++
>  3 files changed, 68 insertions(+), 0 deletions(-)
> 
> diff --git a/QMP/qmp-events.txt b/QMP/qmp-events.txt
> index 01ec85f..cafc4e6 100644
> --- a/QMP/qmp-events.txt
> +++ b/QMP/qmp-events.txt
> @@ -26,6 +26,58 @@ 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.
> +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).  Notice
> +that this event will be changed for 0.14 when we have infrastructure
> +to emit a QError when things fail.

 This is not the kind of information this file should have, compatible
changes should be noted when time comes and incompatible ones are just
forbidden after 0.13.

> +
> +Data: None
> +
> +Example:
> +
> +{ "event": "MIGRATION_FAILED",
> +    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
> +
> +MIGRATION_STARTED
> +-----------------
> +
> +Emitted when migration starts (both in source and target).
> +
> +Data: None
> +
> +Example:
> +
> +{ "event": "MIGRATION_STARTED",
> +    "timestamp": {"seconds": 1274687575, "microseconds": 592483} }
> +
>  RESET
>  -----
> 
> diff --git a/monitor.c b/monitor.c
> index 15b53b9..a5c5388 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -444,6 +444,18 @@ void monitor_protocol_event(MonitorEvent event, QObject *data)
>          case QEVENT_WATCHDOG:
>              event_name = "WATCHDOG";
>              break;
> +        case QEVENT_MIGRATION_STARTED:
> +            event_name = "MIGRATION_STARTED";
> +            break;
> +        case QEVENT_MIGRATION_ENDED:
> +            event_name = "MIGRATION_ENDED";
> +            break;
> +        case QEVENT_MIGRATION_FAILED:
> +            event_name = "MIGRATION_FAILED";
> +            break;
> +        case QEVENT_MIGRATION_CANCELED:
> +            event_name = "MIGRATION_CANCELED";
> +            break;
>          default:
>              abort();
>              break;
> diff --git a/monitor.h b/monitor.h
> index ea15469..34bcd38 100644
> --- a/monitor.h
> +++ b/monitor.h
> @@ -28,6 +28,10 @@ typedef enum MonitorEvent {
>      QEVENT_BLOCK_IO_ERROR,
>      QEVENT_RTC_CHANGE,
>      QEVENT_WATCHDOG,
> +    QEVENT_MIGRATION_STARTED,
> +    QEVENT_MIGRATION_ENDED,
> +    QEVENT_MIGRATION_FAILED,
> +    QEVENT_MIGRATION_CANCELED,
>      QEVENT_MAX,
>  } MonitorEvent;
>

Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Wed,  9 Jun 2010 14:10:56 +0200
> Juan Quintela <quintela@redhat.com> wrote:

>> +MIGRATION_FAILED
>> +----------------
>> +
>> +Emitted when migration fails (both is source and target).  Notice
>> +that this event will be changed for 0.14 when we have infrastructure
>> +to emit a QError when things fail.
>
>  This is not the kind of information this file should have, compatible
> changes should be noted when time comes and incompatible ones are just
> forbidden after 0.13.

Then how you express that this value is going to have a QError in it on
the future?

Adding a Default QError that puts 'This QError is going to be refined'
or what?

Later, Juan.

On Thu, 10 Jun 2010 12:33:42 +0200
Juan Quintela <quintela@redhat.com> wrote:

> Luiz Capitulino <lcapitulino@redhat.com> wrote:
> > On Wed,  9 Jun 2010 14:10:56 +0200
> > Juan Quintela <quintela@redhat.com> wrote:
> 
> >> +MIGRATION_FAILED
> >> +----------------
> >> +
> >> +Emitted when migration fails (both is source and target).  Notice
> >> +that this event will be changed for 0.14 when we have infrastructure
> >> +to emit a QError when things fail.
> >
> >  This is not the kind of information this file should have, compatible
> > changes should be noted when time comes and incompatible ones are just
> > forbidden after 0.13.
> 
> Then how you express that this value is going to have a QError in it on
> the future?

 We don't have to, the doc's purpose is to describe the current state of
the protocol. There might be exceptions, but in this case the change is
compatible and extending the protocol is something that is going to happen
at every release.

 The doc will be updated when the change is introduced.

> Adding a Default QError that puts 'This QError is going to be refined'
> or what?

 We only have to do something like that if having the error information is
something needed right now, which is the case of the BLOCK_IO_ERROR event.