gberche-orange
commented
5 years ago See https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#body-4
a Service Broker that wishes to return dashboard_url for a Service Instance MUST return it with the initial response to the provision request, even if the service is provisioned asynchronously. If present, MUST be a string or null.
Asked clarification about behavior of GET /v2/service_instances/:instance_id w.r.t. dashboard_url returned in https://github.com/openservicebrokerapi/servicebroker/issues/498#issuecomment-507330920
Possible next steps:
Option 1: return inner broker dashboard in GET /v2/service_instances/:instance_id
1- have provisionning response return an initial (fake) dashboard url
- possibly pointing to a static page displaying a message such as "service instance being provisionned"
- possibly configured with a shield url such as
https://shield-webui-m_8b04f44b-ae11-4a94-8dda-1d54fc1b1ce1.((/secrets/cloudfoundry_ops_domain))i.e. configured ashttps://shield-webui-{0}.my-redactedt-ops-domain.comwhere {0} is the service instance guid.
2- implement the GET /v2/service_instances/:instance_id and return instances_retrievable in catalog service offering object
- for inner brokers supporting this endpoint (i.e. , just return provided value from inner broker
GET /v2/service_instances/:instance_idendpoint - for inner brokers not supporting this endpoint, we'd need to record this value returned from provisionning call. Beware some dashboard urls contain sensitive login/password data (such as rabbitmq broker)
- in git templates repo in
coab-depls/c_0a9018b8-7cb2-47c1-9542-0aceb8ca740a/template/coab-vars.yml: currently holds CSIReq (as to share logic withFetching a Service Instanceendpoint)coab-inner-cisresp.yml
- in git secrets repo: in new file
coab-depls/c_0a9018b8-7cb2-47c1-9542-0aceb8ca740a/coab-inner-cisr.yml(along with manifest file written by coa and watched by coab) - in credhub
- in git templates repo in
Limitations of this design:
- a static shield url needs authentication and authorization addressed later in #42
- step 2 addresses rabbitmq dashboard: rabbitmq broker does not current supports
instances_retrievablein version v54.0 from June 14th 2019, see https://github.com/pivotal-cf/cf-rabbitmq-multitenant-broker-release/search?q=instances_retrievable&unscoped_q=instances_retrievable
Likely blocked by CC conformance, see https://github.com/cloudfoundry/cloud_controller_ng/issues/1390
Option 2: Return a dashboard URL served by COAB whose body response content includes a link to the dashboard URL of the inner broker
- record the inner broker dashboard_url returned from provisionning call. Beware some dashboard urls contain sensitive login/password data (such as rabbitmq broker)
- in git templates repo in
coab-depls/c_0a9018b8-7cb2-47c1-9542-0aceb8ca740a/template/coab-vars.yml: currently holds CSIReq (as to share logic withFetching a Service Instanceendpoint)coab-inner-cisresp.yml
- in git secrets repo: in new file
coab-depls/c_0a9018b8-7cb2-47c1-9542-0aceb8ca740a/coab-inner-cisr.yml(along with manifest file written by coa and watched by coab) - in credhub
- in git templates repo in
- implement a new controller to endpoint
/dashboards/{service-instance-guids)/which returns HTML or Json with a list of dashboards- with a statically configured dashboard(s) if configured (e.g. url to shield )
- with the inner broker dashboard url (e.g. rabbitmq dashboard)
In step 2, project this COAB dashboard with SSO
As a service author, I need dashboard returned by nested brokers to be returned to end users. I'm ok to handle authentication for the dashboard (e.g. https url with basic auth credentials in the url) and have it shared among users.
Out of scope: