I added a story for the upgrade use case .
I believe the use case of needing to move the dashboard_url end point that
does not correspond to a service lifecycle event is trickier and is tracked
as part of your github issue . The matching tracker story hadn't been
carried over to the CAPI backlog in the team merge, so it's now back in the
CAPI icebox under consideration.
CF CAPI PM
On Thu, Aug 27, 2015 at 11:06 AM, john mcteague <john.mcteague(a)gmail.com>
There are additional use cases should also be considered.
First, if I upgrade a service, that may come with a new management console
on a different url, I would want this to be reflected.
Additionally, all service instances for a given service may share a
single dashboard, but again, at some point we may need to move the
dashboards endpoint (which may or may not correspond to another service
life cycle event).
On 27 Aug 2015 01:03, "shannon" <scoen(a)pivotal.io> wrote:
Unfortunately, your use use case is not currently supported. dashboard_url
is only supported in the initial response from the broker, even though the
service instance may be asynchronously provisioned. The only workaround I
can think of is to predict the url, though it may not be initially
I recognize this as a valid use case, and have asked Dieu (PM for CAPI,
responsible for the broker API) to consider it for prioritization.
I suggest that we enhance the response to
/v2/service_instances/:guid/last_operation so that when
a header is returned that links to a new endpoint GET
/v2/service_instances/:guid. This endpoint could expose a value for
dashboard_url that wasn't returned in the initial response.
View this message in context:
Sent from the CF Dev mailing list archive at Nabble.com.