delete unused CRD after operator uninstall

[zfrhv]

Feature Request

Is your feature request related to a problem? Please describe.
Each time after deleting an operator, we have to maually delete all of the CRD's.
not only its not that easy, but its also a lot of work
and some people dont even know to deal with operators, all they need is to press the install and uninstall button

the cluster if full with many different types of crd's that are being collected as trash

Describe the solution you'd like
I understand that some CR that werent deleted or forgotten are dependent on the CRD.
so would it be possible at the end of operator uninstallation to see which CRD is not being used,
and if its not being used then delete that crd?

(being used i mean no any custom resource exists)

[dmesser]

Thanks for filing this. This intentionally not being done today. The reason is the destructive nature of deleting CRDs - it will also delete all custom resource instances of the associated CRD. So there is real possibility of data loss here, if all you wanted to do is temporarily remove the controller part of the operator. Also, as part of OLMs control loops the way operators get updated today their on-cluster representation (ClusterServiceVersion) is being removed and replace with a newer one. So there is potential for race conditions and bug that could inadvertently cause the CRD removal to be triggered which will have severe consequences.

That's why the decision has been made to push this to the client side. The kubectl plugin allows you to list all instantiated CRs of an operator and pipe them over to a kubectl delete and then run the uninstall.

[exdx]

It's also worth noting that this behavior (leaving CRDs on the cluster during uninstall) is not always expected by users and I believe something that is being moved away from in the new OLM APIs. It may make the most sense to have the cleanup be configurable on a per operator install basis, or simply changing the default behavior to remove everything (and risk data loss on the user end).

[zfrhv]

hello, thanks for the fast replies !

i see that removing the CRD may harm the CR instances, but wouldnt it be possible to at least check if there are no cr instances, and if not then remove the CRD?

for the user to make sure that there are no CR instances is a lot easier than CRD (because they created the cr).

seems fair to me that if OLM created the CRD, then he should also remove it (or at least try to)

thanks ~

[exdx]

OLM in its current form will probably never remove CRDs, even though it is reasonable to do so. I think in the newer OLM APIs we will have some form of safe CRD deletion by default.

[zfrhv]

nice !
in case it doesnt has desired api, then i expect from the operator to at least check if the crd is safe for deletion and then delete

so as this will take a while, should i close this case or remain it open untill its solved?

[exdx]

You can leave it open, we see requests like this from time to time, we can track them using this issue. If there is a really large consensus around implementing it in OLM in its current form then we can reprioritize.