You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When implementing managed service unprovision we decided that we would ignore errors (note, this method does not return error intentionally) when finalizing. The motivation was that we should perform a best-effort to delete resources and get the instance deleted as quickly as possible.
and SHOULD keep trying to delete them until the Service Broker responds with a success
Acceptance
GIVEN I have created a managed service instance WHEN I try to delete the instance WHEN the broker returns an error response to the unprovision request THEN the instance is not deleted AND THEN I see the broker receives new unprovision requests for that instance
GIVEN I have created a managed service instance WHEN the broker is not there (someone has deleted it) WHEN I try to delete the instance THEN the instance is not deleted
GIVEN I have created a managed service instance WHEN the service offering is not available (someone deleted it for some reason) WHEN I try to delete the instance THEN the instance is not deleted
GIVEN I have created a managed service instance WHEN the service plan is not available (someone deleted it for some reason) WHEN I try to delete the instance THEN the instance is not deleted
Dev notes
instance purging should address instances becoming not deletable
If an isntance is purged, how should that affect its bindings? Should we ignore the error when getting the instance during finalization? Should the binding become unready/failed if its instance is gone?
While being here, make use of the utility to get service instance context in the controller:
danail-branekov
changed the title
As a Korifi user, I want service instances not to be deleted when unbinding fails for whatever reason
As a Korifi user, I want service instances not to be deleted when unprovisioning fails for whatever reason
Nov 4, 2024
Added if staetement in OSBAPI CLient for unrecoverable errors and
implemented polling to Deprovision last operation. Also, when
deprovision fails the instance is not deleted, it sets the failed state
to instance the last operation
fixescloudfoundry#3586
Added if staetement in OSBAPI CLient for unrecoverable errors and
implemented polling to Deprovision last operation. Also, when
deprovision fails the instance is not deleted, it sets the failed state
to instance the last operation
fixescloudfoundry#3586
WIP
Co-authored-by: Danail Branekov <[email protected]>
Background
When implementing managed service unprovision we decided that we would ignore errors (note, this method does not return error intentionally) when finalizing. The motivation was that we should perform a best-effort to delete resources and get the instance deleted as quickly as possible.
However, according to the osbapi spec,
Acceptance
GIVEN I have created a managed service instance
WHEN I try to delete the instance
WHEN the broker returns an error response to the unprovision request
THEN the instance is not deleted
AND THEN I see the broker receives new unprovision requests for that instance
GIVEN I have created a managed service instance
WHEN the broker is not there (someone has deleted it)
WHEN I try to delete the instance
THEN the instance is not deleted
GIVEN I have created a managed service instance
WHEN the service offering is not available (someone deleted it for some reason)
WHEN I try to delete the instance
THEN the instance is not deleted
GIVEN I have created a managed service instance
WHEN the service plan is not available (someone deleted it for some reason)
WHEN I try to delete the instance
THEN the instance is not deleted
Dev notes
korifi/controllers/controllers/services/osbapi/assets.go
Line 74 in 56e6701
The text was updated successfully, but these errors were encountered: