-
Notifications
You must be signed in to change notification settings - Fork 360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add none recursive service instance deletion parameter #3532
Comments
Interestingly, it looks like the v6 CLI doesn't even make the delete request if you still have bindings:
|
yes, I noticed it also when I was investigating this and was surprised. This improvement will require less efforts on CF API clients side and will provide an "atomic" none recursive deletion. So, it is nice to have. |
I checked, and the v7 CLI has the same behavior as v6:
|
I dug up some stories from when the v8 command was originally introduced:
Based on those, it looks like the current v8 behavior was intentional. Not saying that this is the correct behavior that we want to continue with, but it wasn't an oversight. |
cloudfoundry/cli#1839 explicitly requested recursive service instance deletion (i.e. including all service bindings). This is now the standard behaviour of CF API v3 and cf8. The rational was that A possible solution might be to change |
Issue
The service instance deletion API in V3 deletes a service instance recursively. The default behaviour of the V2 APIs is none recursive and there is a parameter called
recursive
which can be used to have a recursive deletion. The recursive deletion for service instances is challenging because they could have bindings which also get deleted but apps using the bindings will still have a reference to the binding and will fail by trying to access the service via it.Steps to Reproduce
cf delete-service <my-service-instance>
https://<my-app-host>/appinfo
that the app is still bound to the serviceExpected result
With the current approach in CF to require a restage for service binding updates I don't think that this could be solved but we could provide a none recursive alternative.
Possible Fix
In case a CF API client wants to implement a none recursive deletion it will be useful to provide a parameter to disable the recursive deletion.
The text was updated successfully, but these errors were encountered: