Should finalizers be automatically generated for native Kubernetes resources?

[metacosm]

While it makes sense to automatically generate finalizers for reconcilers handling custom resources, it might actually be dangerous to do so for reconcilers handling native Kubernetes resources as doing so might impact the cluster's behavior by preventing the cluster to delete resources it owns… What do people think?

[csviri]

It's still can be turned off, but in my opinion the possibility should be there. This contract of having there a finalizer or multiple finalizers comes from Kubernetes, will block deleting the resource, but the secondary operator will eventually remove it.

[metacosm]

The question is not whether this should be completely impossible, which it isn't. Indeed, it should be possible to add finalizers if needed.
The question is more about knowing whether this should be done by default like we do for CustomResource instances.

[csviri]

I think it is even questionable for custom resources, usually it is just needed when managing K8S resources or not able to set ownerReference. Maybe both cases the default should be no finalizer.

[metacosm]

Indeed, maybe. Would love to hear from our users on the topic… 😄

[scrocquesel]

Have you consider splitting the reconciler interface to explicitly have a cleanup interface ? This way finalizer could be turn off by default and if the controler implement the cleanup interface, it is turned on.
From a user pov, it makes no sense to implement cleanup method and opt-in by configuration.

[csviri]

@scrocquesel
Probably this would be the best to do!
Maybe have a separate annotation to configure the name of the finalizer.