The Deleter and Garbage Collector issuer with Kuberentes Dependent Resources

[csviri]

In Dependent Resources Deleter means that the resources needs to be explicitly deleted during a cleanup. However also implies that the resource is coupled to the custom resource in a sense that during the reconciliation this resource might be deleted. See:

https://github.com/java-operator-sdk/java-operator-sdk/blob/d7498cc833efe447eb50467fd8fb8f13da79adc3/sample-operators/webpage/src/main/java/io/javaoperatorsdk/operator/sample/WebPageStandaloneDependentsReconciler.java#L68-L72

For managed dependent resources this is handled automatically by the system, also means that finalizer will be utilized for the custom resource.

For managed dependent resources there is an issue with this in terms of deleting, regarding the resources which are garbage collected rather then explicitly deleted. Note that in scope of v3.0.0 the deletion during a reconciliation was out of the scope for managed resources. But with workflows this will be introduced, see: #850 (If Condition not holds, the resource should be deleted during the reconciliation)

Issue / Goal

The issue is that for Kubernetes dependent resources where owner references can be used, we want to have the resource Deleter if it might be deleted also during the reconciliation, but we don't want to use finalizers because of this, and we don't want to explicitly delete the dependent during cleanup phase, rather the k8s garbage collection needs to clean it up.

Proposed Solution

A way we could handle this globally is to introduce a GarbageCollected empty marker interface, that when implemented in combination with Deleter, would have the desired effect as describe above. Thus the resource might be deleted explicitly during the reconciliation, but won't be at cleanup, and finalizer won't be added because of this resources.

[csviri]

Note this makes sense mainly for more generic Workflows where delete in reconciliation is actually happening.
See: https://github.com/java-operator-sdk/java-operator-sdk/blob/17f96180224f67a9e39992c8ab2c8b7908ef8942/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/dependent/workflow/WorkflowReconcileExecutor.java#L146

[csviri]

check: garbage collector makes sense only if owner references can be added. So it is loosely coupled also with SecondaryToPrimaryMapper.