Closed elgohr closed 5 years ago
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.
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:
At my point of view https://github.com/openservicebrokerapi/servicebroker/pull/670 sounds like the first type of lifecycle actions.
I believe #670 is actually the latter (it is service instance extensions, rather than service broker extensions), but @Samze could you confirm for me?
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.
Sounds good.
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
To be discussed: Would 404 also be a valid value, if the service is gone?