1. Messages
  2. Update Dashboard URL with Asynchronous Provisioning

Re: Update Dashboard URL with Asynchronous Provisioning

john mcteague <john.mcteague@...>
 

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

John

On 27 Aug 2015 01:03, "shannon" <scoen(a)pivotal.io> wrote:

Hello Robert,

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

I recognize this as a valid use case, and have asked Dieu (PM for CAPI, now
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 "state":"succeeded"
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.

Best,
Shannon



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Update-Dashboard-URL-with-Asynchronous-Provisioning-tp1313p1377.html
Sent from the CF Dev mailing list archive at Nabble.com.

?
attachment.html

Join {cf-dev@lists.cloudfoundry.org to automatically receive all group messages.