Bug 2015023

Sorry for the slow response!

@dgautam I'm going to need the status of the Operator resource _after_ the deletion attempt is made. That status should show any remaining components. Without that info, I can only suspect that some cluster scoped resources still exist that reference the Operator -- e.g. a CRD -- since I have been unable to reproduce the issue myself.

A must-gather will help too.

Hi Dhruv,

We've brought this change downstream on this PR: https://github.com/openshift/operator-framework-olm/pull/278

I'll update this ticket to ON_QA

Cheers,

Per

oc get clusterversion 
NAME      VERSION                              AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.11.0-0.nightly-2022-04-07-053433   True        False         4h25m   Cluster version is 4.11.0-0.nightly-2022-04-07-053433

oc exec olm-operator-67fc464567-8wl9l  -n openshift-operator-lifecycle-manager -- olm --version
OLM version: 0.19.0
git commit: 491ea010345b42d0ffd19208124e16bc8a9d1355

cat og-single.yaml 
kind: OperatorGroup
apiVersion: operators.coreos.com/v1
metadata:
  name: og-single1
  namespace: default
spec:
  targetNamespaces:
  - default

oc apply -f og-single.yaml 
operatorgroup.operators.coreos.com/og-single1 created

cat teiidcatsrc.yaml 
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: teiid
  namespace: default
spec:
  displayName: "teiid Operators"
  image: quay.io/bandrade/teiid-index:1898500
  publisher: QE
  sourceType: grpc

oc create -f teiidcatsrc.yaml 
catalogsource.operators.coreos.com/teiid created

cat teiidsub.yaml 
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: teiid
  namespace: default
spec:
  source: teiid
  sourceNamespace: default

  channel: alpha
  installPlanApproval: Automatic
  name: teiid

oc apply -f teiidsub.yaml 
subscription.operators.coreos.com/teiid created

oc get sub -n default                               
NAME    PACKAGE   SOURCE   CHANNEL
teiid   teiid     teiid    alpha

oc get ip -n default      
NAME            CSV            APPROVAL    APPROVED
install-psjsf   teiid.v0.3.0   Automatic   true

oc get csv
NAME           DISPLAY   VERSION   REPLACES   PHASE
teiid.v0.3.0   Teiid     0.3.0                Succeeded

oc get operators -n default
NAME                                                AGE
cluster-logging.openshift-logging                   5h14m
elasticsearch-operator.openshift-operators-redhat   5h14m
teiid.default                                       13m

oc delete sub teiid
subscription.operators.coreos.com "teiid" deleted

oc delete csv teiid.v0.3.0
clusterserviceversion.operators.coreos.com "teiid.v0.3.0" deleted

oc get operator teiid.default -o yaml
apiVersion: operators.coreos.com/v1
kind: Operator
metadata:
  creationTimestamp: "2022-04-07T23:22:22Z"
  generation: 1
  name: teiid.default
  resourceVersion: "146694"
  uid: d74c796d-7482-4caa-96ed-fbd401a35f19
spec: {}
status:
  components:
    labelSelector:
      matchExpressions:
      - key: operators.coreos.com/teiid.default
        operator: Exists


oc delete operator teiid.default -n default                                                                   1 ↵
warning: deleting cluster-scoped resources, not scoped to the provided namespace
operator.operators.coreos.com "teiid.default" deleted


oc get operator teiid.default -o yaml
Error from server (NotFound): operators.operators.coreos.com "teiid.default" not found

LGTM, marking as VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5069

This bug is being referenced by many teams when they encounter an operator CR that cannot be deleted. Typically, this issue is seen when a user hasn't cleaned up all resources associated with the operator CR, the steps to do so are detailed here [1]. If the operator CR still has components listed in its `status.Components` array, OLM is working as intended.


The PR that is associated with this bug fixed an issue where the `operator CR` could not be deleted even if no components were associated with the `operator CR`. This bug fix will not be backported to 4.9 as that version of OLM is in maintenance mode.

Thanks,

Alex

Ref:
[1] https://github.com/operator-framework/olm-docs/pull/251/files

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days