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
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
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
> -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
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
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
