servicebroker
servicebroker copied to clipboard
openservicebrokerapi
Allow Service Brokers to indicate the state of a Service Instance after a failed update or deprovisioning
When an instance update or delete fails, the platform doesn't know the state of the instance and doesn't know if the operation can be repeated. This PR allows brokers to provide this additional information to the platform in case of a failure.
This PR replaces PR #570.
@georgi-lozev I agree. The right approach would be to return these states in the response of the fetch endpoint. But there are brokers that cannot provide a fetch endpoint. The only way I can think of that works for all brokers to transport this information is the error response. Do you have a better idea?
This seems reasonable from a k8s perspective. We'd have to plumb this through to our controller, but most of these values already have corresponding values in our reconciliation logic that these could be plugged into
Thinking a bit more about this, I think this PR does 3 things:
- (Feature 1) Adds a mechanism to denote health/usability of a service instance.
- (Feature 2) Adds a mechanism to denote if subsequent updates are possible on a service instance
- (Feature 3) Adds a mechanism to inform the platform when the subsequent update can be trigged
A comment on Feature 3:
Are we are exposing the complexity of the retrying mechanism at two places in the spec, which I think is unnecessary. I think broker authors can leverage the existing Retry-After header to signify that the operation is still in progress today.
Today retry of an update can be encapsulated in the Last Operation invocation:
Where as after this PR, in addition to the above mechanism broker authors will also have the ability to retry the update itself:
What are the benefits of introducing an alternate mechanism for retry? Can we achieve the same result by adding the health/usability indicator to last operation?
