Indicate if a Service Instance is still usable after a failed update or deprovisioning and if an update can be repeated#661
Conversation
|
✅ Hey fmui! The commit authors and yourself have already signed the CLA. |
spec.md
Outdated
|
|
||
| When a deprovisioning fails, the Service Instance can still be usable or | ||
| unusable or its state could be unknown. If a Service Instance became unusable, | ||
| the Platform SHOULD NOT allow the creation of new bindings. |
There was a problem hiding this comment.
I'm not sure if this is just me being pedantic, but don't we generally try to describe things in terms of the platform/broker relationship? As currently worded, this seems to be more describing the internal behavior of the platform itself. Wouldn't it make more sense if it was worded something like "If a Service Instance becomes unusable the Platform SHOULD NOT request new Service Bindings for that Service Instance."
There was a problem hiding this comment.
Good point. I've changed that sentence.
|
Looks good from SAPI point of view. |
|
@tinygrasshopper we need your vote! |
|
✅ Hey fmui! The commit authors and yourself have already signed the CLA. |
* [ ] Test update https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#response-5 * [x] Implement update error recovery * Check si, if an update operation is in progress, then return 202 accepted, * otherwise 500 bad request if update request was previously accepted * otherwise 400 bad request otherwise * OSB api v2.16 will be supporting error details such as "usable", see cloudfoundry/servicebroker#661 * But not yet implemented in CF API v3 http://v3-apidocs.cloudfoundry.org/version/3.83.0/index.html#create-a-service-instance * Nor in SC-OSB * [x] Refine USI sync success test: sync update will trigger a new backing update and not enter error recovery branch, just perform the update twise * [x] OSB provision dupl same SI: check same dupl receives right status * [x] 200 Ok as backing service was completed
…ate + handle invalid plan/service-definion id * [x] Test update https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#response-5 * [x] Implement update error recovery * Check si, if an update operation is in progress, then return 202 accepted, * otherwise 500 bad request if update request was previously accepted * otherwise 400 bad request otherwise * OSB api v2.16 will be supporting error details such as "usable", see cloudfoundry/servicebroker#661 * But not yet implemented in CF API v3 http://v3-apidocs.cloudfoundry.org/version/3.83.0/index.html#create-a-service-instance * Nor in SC-OSB * [x] Refine USI sync success test: sync update will trigger a new backing update and not enter error recovery branch, just perform the update twise * [x] OSB provision dupl same SI: check same dupl receives right status * [x] 200 Ok as backing service was completed * [x] Check UpdateAsyncInstanceWithBackingServiceAcceptanceTest does * [x] USI * [x] OSB provision dupl same SI: check same dupl receives right status * [x] 202 accepted, and then 200 * [x] New concurrent stalled Update async test (ConcurrentAsyncUpdateInstanceWithBackingServiceAcceptanceTest) that does * [x] New interceptor StalledAsyncUpdate * [x] USI * [x] OSB provision dupl same SI: check same dupl receives right status * [x] 202 Accepted as backing service is still in progress * [x] OSB update with invalid plan * [x] 400 Bad request
What is the problem this PR solves?
This PR is a subset of PR #637. It only contains the non-controversial
instance_usableandupdate_repeatableflags.Checklist: