Hi,

My service broker provisions a service asynchronously but doesn't get the
management url until the service is provisioned. Currently the poll to the
endpoint /{instanceId}/last_operation doesn't return this field in its body
to update the service. Is there any other way to update the service when
this value becomes available?

Robert

--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP

This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.

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.

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

Hi John,

I added a story for the upgrade use case [1].

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 [2]. 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.

-Dieu
CF CAPI PM

[1] https://www.pivotaltracker.com/story/show/102485224
[2] https://www.pivotaltracker.com/story/show/94657436

On Thu, Aug 27, 2015 at 11:06 AM, john mcteague <john.mcteague(a)gmail.com>
wrote:

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.