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 fr
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 ofthe conductor server
> -Original Message-
> From: Paul Carlton [mailto:paul.carlt...@hpe.com]
> Sent: November 26, 2015 12:11
> 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 Noti
Useful information.
Thank you Gibi.
BR
Shaohe Feng..
2015-11-26 21:29 GMT+08:00 Balázs Gibizer :
> > -Original Message-
> > From: Paul Carlton [mailto:paul.carlt...@hpe.com]
> > Sent: November 26, 2015 12:11
> > On 26/11/15 10:48, 少合冯 wrote:
> >
> >
> > Now, we are agree on getting
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 :
> On 26/11/15 10:48, 少合冯 wrote:
>
> Now, we are agree on getting more migration status d
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 少合冯 :
> Agree. Why not both. and will use created_at to work o
