Bug 1626351
| Summary: | [Regression] Namespace goes in "terminating" state due to unprovisioned ServiceInstance | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Alexis Solanas <asolanas> |
| Component: | Service Catalog | Assignee: | Jay Boyd <jaboyd> |
| Status: | CLOSED NOTABUG | QA Contact: | Zhang Cheng <chezhang> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.9.0 | CC: | aos-bugs, cshereme, jaboyd, jmatthew |
| Target Milestone: | --- | ||
| Target Release: | 4.1.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-17 19:43:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
If the Broker can not successfully delete the resources related to an instance or binding, Service Catalog will not delete the associated Kubernetes metadata (the ServiceInstance or ServiceBinding). This will in turn mean the namespace will not be fully deleted either and will remain in a terminating state. If you examine the ServiceInstance and ServiceBinding with `oc describe ServiceInstance ...` command you should see error details in the status and events about why the Broker failed to delete the instance. If you do not care about the broker resources and just want to get rid of the Service Catalog resources in OpenShift, you can delete the finalizer as detailed here: https://access.redhat.com/articles/3441161 This article has full background on the issue. The --force and --grace-period flags will not assist in deleting these resources in this circumstance. We realize this may not align with your desired behavior, but in some cases users will be charged for Broker resources as long as they are still allocated. If we deleted them from OpenShift even though they can not be released by the Broker users would continue to be charged. We will implement a command to make it easier to remove the finalizer, but for now that is a manual edit you must make. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days |
Description of problem: Whenever the Service Instance is aborted/fails deleting the project goes in "terminating" state and cannot delete the Service Instance also. Version-Release number of selected component (if applicable): # oc version oc v3.9.33 kubernetes v1.9.1+a0ce1bc657 features: Basic-Auth GSSAPI Kerberos SPNEGO openshift v3.9.33 kubernetes v1.9.1+a0ce1bc657 How reproducible: Always Steps to Reproduce: # oc delete project test1 project "test1" deleted # oc get -n test1 all No resources found. # oc get -n test1 ServiceInstance NAME AGE cakephp-mysql-example-rvvvh 5h # oc export project test1 apiVersion: v1 kind: Project metadata: annotations: openshift.io/description: "" openshift.io/display-name: "" openshift.io/requester: simeny openshift.io/sa.scc.mcs: s0:c12,c9 openshift.io/sa.scc.supplemental-groups: 1000150000/10000 openshift.io/sa.scc.uid-range: 1000150000/10000 creationTimestamp: null labels: router: external name: test1 spec: finalizers: - kubernetes status: phase: Terminating # oc delete -n test1 ServiceInstance cakephp-mysql-example-rvvvh --force --grace-period=0 warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely. serviceinstance "cakephp-mysql-example-rvvvh" deleted # oc get -n test1 ServiceInstance NAME AGE cakephp-mysql-example-rvvvh 5h Actual results: 1. The bindings and instance still exist after delete project 2. Project exists in terminating state Expected results: 1. bindings and instance should be removed after delete project Additional info: This issue was fixed in v3.9.31 by https://bugzilla.redhat.com/show_bug.cgi?id=1541350, but it's happening again on v3.9.33