Repository navigation
Add "OwnerType" Annotation for Non-GC'ed DependentResources #2585
Description
I have a reconciler that extends KubernetesCRUDNoGCDependentResource. The created dependent has the following annotations:
metadata:
annotations:
io.javaoperatorsdk/primary-name: my-thing
io.javaoperatorsdk/primary-namespace: my-namespace
In my operator, I have several different CustomResourceDefinitions and reconcilers. Therefore, I can and do have multiple custom resources in the my-namespace namespace called my-thing.
In my own code, I need to determine the owner of these resources. I can solve that by putting labels/annotations on them myself (this is quite a bit of work). However, I imagine that this is likely a vulnerability to bugs.
Proposed Solution
Add another annotation to NoGC resources and use that for determining ownership:
metadata:
annotations:
io.javaoperatorsdk/primary-type: MyCustomResource
Reacted by Chris Laprun and Attila Mészáros
Activity
metacosm commentedon Nov 16, 2024
I need to double check but isn't the type of the primary known when the annotations are used?
metacosm commentedon Nov 16, 2024
Indeed, the owner type is not known. However, this will require deeper changes than simply adding the annotation because the mappers only return
ResourceIDinstances, which, currently, only also record name and namespaces.csviri commentedon Nov 16, 2024
@metacosm I'm pretty sure we don't need to extend resourceID, note that from v5 we do type checking for owner references, adding type annotation should do the trick, and have the secondary filter on the.
Another option is just use labels/ label selectors, which is also more efficient.
or rather both. But something like the primary type should be there fo sure - preferably a GroupVersionKind (GVK) as a value in some form.
csviri commentedon Nov 17, 2024
#2586
added scretch how the impl could look like, will finalize it bit later. @coltmcnealy-lh should we backport it into 4.x or you are ok to wait for v5?
coltmcnealy-lh commentedon Nov 17, 2024
@csviri we have a workaround, which is just overriding a bunch of
getSecondaryResourcesmethods to use theKubernetesClientdirectly and filter based on labels that we manually put onto our dependents. We can wait until v5 (we do our best to stay up-to-date with the JOSDK). Just thought I'd report this in case someone else is affected.Thanks for the prompt response!
coltmcnealy-lh commentedon Jan 24, 2025
I see that #2606 was merged. Should this ticket be closed?
metacosm commentedon Jan 24, 2025
Indeed.