Standalone dependent resource of type CRUDNoGCKubernetesDependentResource not deleted after removal of primary custom resource

[ivanchuchulski]

Hello,
We're writing an Operator and so far we've chosen to use the standalone dependent resources option in our Reconciler implementation. We were initially using the CRUDKubernetesDependentResource as the main class, that we extend in our dependent resources, but we've decided to switch to CRUDNoGCKubernetesDependentResource, in order to avoid the inability to have cross-namespace owner references, because we have cases, where we have dependent resources outside of the namespace of the primary custom resource and cluster-scoped resources, like ClusterRole, which also can't have an owner reference to a namespaced custom resource.

However, the issue we're facing now is when deleting the primary custom resource, the respective dependent resources aren't removed from the cluster. As far as I understood from the docs and observed in the cluster, when using CRUDNoGCKubernetesDependentResource, the mapping between the primary and dependent resources is achieved through a couple of annotations, that are inserted into the metadata of every dependent resource. Having said that I'd like to ask you the following questions:

1. What is the best approach to properly cleanup the standalone dependent resources when their primary resource is deleted? Is it a valid case, if we implement the Cleaner interface in our reconciler and we manually delete each dependent resource by calling it's delete(P primary, Context<P> context) method, which is defined in AbstractDependentResource? Will the the framework have any troubles figuring out exactly what dependent resource to delete, in the case we have more that one primary custom resource in the cluster?
2. Is there any way to customize the keys of the annotation, that are inserted into the dependent resources, when they're of type CRUDNoGCKubernetesDependentResource or they must be hard-coded to io.javaoperatorsdk/primary-name and io.javaoperatorsdk/primary-namespace?

Environment

Kubernetes cluster type: Kubernetes v1.25.3 on Minikube v1.28.0

$ Mention java-operator-sdk version from pom.xml file

4.4.2

$ java -version

openjdk version "17.0.8" 2023-07-18 LTS

$ kubectl version

1.25.0

[csviri]

Hi @ivanchuchulski

1. yes, in this case the cleaner should be implemented and explicitly called on the workflow / dependent resources. Framework should figure out the rest.

2. As far I can see now, it is not trivial to configure the names of the annotations now. It should be, will create an issue for that and imlpement it for the next minor release. (see: see: Support Custom Referencing of Primary Resource From Kubernetes Dependent Resource #2074 )

[csviri]

Prepated the PR with a sample: #2075