Proposal: Introduce a health endpoint url

[elgohr]

What is the problem?
At the moment services, which are provided by the broker, don't have a way to tell the consumer whether they're working correctly or not. Using the Dashboard-Url (https://github.com/openservicebrokerapi/servicebroker/blob/v2.15/spec.md#body-4) would be a way to provide this for humans. Nevertheless it would be nice to have a unified way to provide this also to services.

Who does this affect?
Service Broker Authors & Developers

Do you have any proposed solutions?
Add an additional optional field for a health check endpoint

Response Field	Type	Description
dashboard_url	string	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. If present, MUST be a string or null.
operation	string	For asynchronous responses, Service Brokers MAY return an identifier representing the operation. The value of this field MUST be provided by the Platform with requests to the Polling Last Operation for Service Instances endpoint in a percent-encoded query parameter. If present, MAY be null, and MUST NOT contain more than 10,000 characters.
health_url	string	If provided, the URL MUST return Http-Status 200 (Ok) if the service is up and working or Http-Status 503 (Service Unavailable) if the service is not working correctly.

To be discussed: Would 404 also be a valid value, if the service is gone?

[mattmcneeney]

He @elgohr - thanks for raising this issue!

Health checks is actually one of the key workflows we were hoping to unblock with the Generic Extensions work (#670). I'm interested to know if you took a look at that and if it would be suitable for this use case? My hope would be that those service brokers which can support this kind of workflow (not all can) would adhere to a common 'health' extension and would therefore support a defined OpenAPI document detailing a health check endpoint that could return 200/503 as you say.

[elgohr]

Hi @mattmcneeney , thank you for pointing out the Generic Extensions - indeed I didn't know about them.
Generic Extensions might solve the problem, but I think we should differentiate two things:

• lifecycle actions of the service broker (when you want to update service A or do other maintainance work with the broker)
• lifecycle actions of the service A itself (health-check, service metrics, ...)

At my point of view #670 sounds like the first type of lifecycle actions.

[mattmcneeney]

I believe #670 is actually the latter (it is service instance extensions, rather than service broker extensions), but @Samze could you confirm for me?

[Samze]

Yes #670 is for service instance operations only. We imagined there might be a follow up proposal that would introduce generic extensions on a service broker itself.

[elgohr]

Sounds good.