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 少合冯 <[email protected]>: > 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 <[email protected]>: > >> 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:[email protected] <[email protected]> >> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
