CSV not removed after deletion when not in Success/Terminal state.

[tmshort]

Bug Report

It appears that CSVs may not be deleted when they are "deleted". The CSV remains after a deletion attempt, which means that all resources associated with (owned by) the CSV remain.

See #3108

What did you do?
Happens during e2e (Install Plan creation with permission), it's a flake.

When a CSV is not in a (e.g.) success state, and it's deleted, it's not actually deleted.

What did you expect to see?
When a CSV is deleted, the CSV is deleted regardless of the state it's in.

What did you see instead? Under which circumstances?
When the CSV is deleted, it remains.

Environment

• operator-lifecycle-manager version: master
• e2e tests

• Kubernetes version information: e2e test (most recent)

• Kubernetes cluster kind: openshift and kind

[stevekuznetsov]

This does not really have to do with the state that the CSV is in. The controller, as written today, is edge-driven. If it ever misses a deletion event, since there is no finalizer, you are not guaranteed that the clean-up code runs. It might be the case, in that end-to-end test, that waiting for the controller to see the CSV by not deleting until a specific state is enough to make sure the event is not missed, but it's not a generic fix to the issue.

[tmshort]

What appears to be happening is that the CSV is being re-created by the Subscription, as the UIDs are different. With some of the performance enhancements, this is occurring a lot quicker now.