Open Stack

I agree we should have both(notification/API).

Watcher will consume notifications, not the API, API would be helpful for
operator.

The notification way should be addressed in separate BP.

BR,
YunTongJin

2015-11-26 22:37 GMT+08:00 少合冯 <lvmxhster at gmail.com>:

> Agree.  Why not both.  and will use created_at to work out how long the
> migration has been
> running.
>
>
> Paul, thank you very much for the suggestion.
>
> BR.
> Shaohe Feng
>
>
>
> 2015-11-26 19:10 GMT+08:00 Paul Carlton <paul.carlton2 at hpe.com>:
>
>> On 26/11/15 10:48, 少合冯 wrote:
>>
>> Now, we are agree on getting more migration status details info are
>> useful.
>>
>> But How do we get them?
>> By REST API or Notification?
>>
>>
>> IF by API, does the  "time_elapsed" is needed?
>> For there is a "created_at" field.
>> But IMO, it is base on the time of the conductor server?
>> The time_elapsed can get from libvirt, which from the hypervisor.
>> Usually, there are ntp-server in the cloud. and we can get the
>> time_elapsed by "created_at".
>> but not sure there will be the case:
>> the time of hypervisor and conductor server host are out of sync?
>>
>> Why not both.  Just update the _monitor_live_migration method in the
>> libvirt
>>  driver (and any similar functions in other drivers if they exist) so it
>> updates
>>  the migration object and also sends notification events.  These don't
>> have
>>  to be at 5 second intervals, although I think that is about right for
>> the
>> migration object update.  Notification messages could be once event 30
>>  seconds or so.
>>
>> Operators can monitor the progress via the API and orchestration utilities
>>  to consume the notification messages (and/or use API).
>> This will enable them to identify migration operations that are not making
>>  good progress and take actions to address the issue.
>>
>> The created_at and updated_at fields of the migration object should be
>> sufficient to allow the caller to work out how long the migration has been
>> running for (or how long it took in the case of a completed migration).
>>
>> Notification payload can include the created_at field or not.  I'd say
>> not.
>> There will be a notification message generated when a migration starts
>> so subsequent progress messages don't need it, if the consumer wants
>> the complete picture they can call the API.
>>
>>
>> --
>> Paul Carlton
>> Software Engineer
>> Cloud Services
>> Hewlett Packard
>> BUK03:T242
>> Longdown Avenue
>> Stoke Gifford
>> Bristol BS34 8QZ
>>
>> Mobile:    +44 (0)7768 994283
>> Email:    mailto:paul.carlton2 at hpe.com <paul.carlton2 at hpe.com>
>> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England.
>> The contents of this message and any attachments to it are confidential and may be legally privileged. If you have received this message in error, you should delete it from your system immediately and advise the sender. To any recipient of this message within HP, unless otherwise stated you should consider this message and attachments as "HP CONFIDENTIAL".
>>
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151127/6c1fab8b/attachment.html>