-
Notifications
You must be signed in to change notification settings - Fork 382
Policy for handling broker deletion and deprovision #481
Comments
Not going to be in 0.0.2 |
Moving out of a milestone until we decide what to do here. |
Added 1.0.0 since we need to decide before v1. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
/assign |
we started working on that, see: kyma-project/kyma#5180 more details will be presented soon |
At our last face-to-face meeting in late January 2017, we discussed what the system should do on a broker deletion and deprovision operation.
On a deprovision operation, we decided that the default case is to fail the deprovision if there are bindings against the instance being deprovisioned. A "force" or "cascade" flag can be explicitly set on the call to make all bindings be unbound, and then the deprovision be done.
We decided on a similar strategy for broker deletion.
This issue is for discussing how we are going to achieve this functionality in
kubectl
. The CLI provides a--cascade
and--force
flag that we should consider utilizing for this purpose.The text was updated successfully, but these errors were encountered: