[FR] Support for service broker dashboards

[gberche-orange]

Is your feature request related to a problem? Please describe.

As a cloud-service-broker user (e.g a CF developer provisionning AWS RDS through CSB)

• in order to finely manage the provisionned resource
  • AWS RDS backups/snapshots
  • access to AWS RDS metrics
• I need CSB to enable returning a service dashboard

Currently, CSB seems to always return an empty dashboard url

https://github.com/pivotal/cloud-service-broker/blob/99dab14683fc429dbcb04bb4c025cfa6fe378480/brokerapi/brokers/service_broker.go#L168

https://github.com/pivotal/cloud-service-broker/blob/99dab14683fc429dbcb04bb4c025cfa6fe378480/brokerapi/brokers/service_broker.go#L584

Describe the solution you'd like

A way to specify the dashboard in the provision action by selecting an input.

Describe alternatives you've considered

Additional Context

Regarding ways cloudfoundry end user would authentify to the AWS RDS dashboard, I would expect that support for AWS IAM external users would enable a brokerpak to provision web identity federation and restricted IAM role so that a CF signed in user would be granted just enough permission to access the AWS RDS console to list backups/snapshots and restore them in a self service maneer.

Priority

Priority Context

Platform

Applicable Services

Does this apply to all services? Just one? Let us know

Most data services need access to backup/restore/metrics/logs.

The OSB API group has not yet prioritized associated work, see openservicebrokerapi/servicebroker#486 openservicebrokerapi/servicebroker#485 openservicebrokerapi/servicebroker#107, therefore service providers have no other choices than direct users to a web ui through the dashboard url.

[omerbensaadon]

Keep the Issues coming!

[erniebilling]

@gberche-orange This is a great idea, but probably won't work with the current OSBAPI spec.

The problem is that the URL must be generated during the provision call. Since the provision is async, the values that would be used to generate the URL aren't known and there is no current support in OSBAPI to update the URL.

From https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md

The URL of a web-based management user interface for the Service Instance; we refer to this as a service dashboard. The URL MUST contain enough information for the dashboard to identify the resource being accessed (9189kdfsk0vfnku in the example below). Note: 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.

[gberche-orange]

thanks for looking into this suggestion @erniebilling

What about returning a static dashboard url served by CSB (e.g. including the service instance guid as param). When this dashboard url is queried by developers, it then redirects to the (asynchronously computed) value of a terraform output, possibly an url to a provisionned cloud resource (such as an RDS instance guid) ?

[erniebilling]

We're adding the ability for the bokerpak terraform to set a custom message that will be displayed as part of the output from cf service <service instance> This message is updated once the async provision operation is complete. Here's some sample output I've been playing with:

name:            test-mssql
service:         csb-azure-mssql
tags:            
plan:            small
description:     Azure SQL Database is a fully managed service for the Azure Platform
documentation:   https://docs.microsoft.com/en-us/azure/sql-database/
dashboard:       

Showing status of last operation from service test-mssql...

status:    create succeeded
message:   created db csb-db (id:
           /subscriptions/899bf076-632b-4143-b015-43da8179e53f/resourceGroups/broker-cf-test/providers/Microsoft.Sql/servers/csb-azsql-9a19e6ea-5350-4377-9cd8-d7686bbb93a2/databases/csb-db) on
           server csb-azsql-9a19e6ea-5350-4377-9cd8-d7686bbb93a2 (id:
           /subscriptions/899bf076-632b-4143-b015-43da8179e53f/resourceGroups/broker-cf-test/providers/Microsoft.Sql/servers/csb-azsql-9a19e6ea-5350-4377-9cd8-d7686bbb93a2) URL:
           https://portal.azure.com/#@29248f74-371f-4db2-9a50-c62a6877a0c1/resource/subscriptions/899bf076-632b-4143-b015-43da8179e53f/resourceGroups/broker-cf-test/providers/Microsoft.Sql/servers/csb-azsql-9a19e6ea-5350-4377-9cd8-d7686bbb93a2/databases/csb-db
started:   2020-09-17T19:54:32Z
updated:   2020-09-17T19:56:40Z

There are no bound apps for this service.

[gberche-orange]

Thanks, this is a nice 1st step! Any reason not to try to return the url into the dashboard field ?

As you probably know, using the status message to provide dashboard urls has the following limitations:

• discoverability and formatting. Cf UIs such as PWS or stratos don't display status message in most views, or don't detect Urls in status messages, making is harder for users to click on the url. Dashboards are properly formatted as hrefs with proper UX (manage href in PWS)
  
  

• status message might be ephemeral (see for instance recent related CAPI regression at capi 1.97.0 breaking change: "cf set-label service-instance" swallows service instance status and message cloud_controller_ng#1847) and disappear upon service instance plan update, or params update if the broker does not reissue it.

[erniebilling]

It may not always be possible to generate the URL before the terraform has completed. But we can investigate adding support for those cases when it can be generated.

[gberche-orange]

As mentionned in #81 (comment), one possibility is to return a static dashboard url served by CSB e.g. https://csb-deployment.domain/dashboard?service-instance-guid=guid. When the user requests this endpoint, then CSB looks up the URL stored in database (once terraform apply completes) and returns one if available or an error page such as "dashboard is not yet available while the instance is being provisionned".

To avoid returning dashboard urls that always redirect to an error page, the dashboard feature would be an opt-in actionned by brokerpak authors.

[omerbensaadon]

hey @gberche-orange, we have unfortunately de-prioritized this feature as it may be difficult to implement for customers leveraging multiple accounts (which we have nascent plans to begin supporting).

If I don't hear back from you, I'll close this issue! Sorry to disappoint.

[gberche-orange]

Thanks @omerbensaadon for the follow up. I don't quite understand the 'multiple account' use-case you mentioned that would not be supported by the dashboard feature. Can you please elaborate that use-case more precisely?

[omerbensaadon]

@gberche-orange I will have ENG follow up in a bit here...

[erniebilling]

You are right @gberche-orange, the multiple account use case probably doesn't impact this feature, but unfortunately, the priority for this feature is pretty low at this time. Happy to take a PR from some intrepid contributor that feels this feature is in their wheel house.

[gberche-orange]

Implementation of this feature for cloudfoundry clients is now made much easier with cloudfoundry/cloud_controller_ng#1390 (comment) contributed by @FelisiaM in cloudfoundry/cloud_controller_ng#2116 : the dashboard url can now be returned in the GET /v2/service_instances/:instance_id/last_operation, i.e. once the terraform apply has complete, and one output variable was returned specifying the dashboard URL value.

This makes it possible to have the returned dashboard url be more precise and include reference to ids generated during terraform apply, such as https://console.cloud.google.com/sql/instances//overview?project=&authuser=2

[pivotal-marcela-campo]

Hi @gberche-orange , we won't be able to tackle this anytime soon. You are welcome to submit a PR for this feature if you still want it.

[gberche-orange]

thanks for the update macela.