Provide generic API to update metadata.ownerReferences field

[rombert]

I am creating a kubernetes job and some associated resources ( secrets, network policies ). The job is auto-deleted using the .spec.ttlSecondsAfterFinished field.

Since kubernetes can not clean up the associated resources automatically, I am trying to update the .metadata.ownerReferences field after creating all resources and the job.

The code is essentially

            Job owner = r.getValue().getOwner();
            OwnerReference ref = new OwnerReference(owner.getApiVersion(), false, true, owner.getKind(), owner.getMetadata().getNamespace(), owner.getMetadata().getUid());
            logger.debug("Adding {} as owner reference for created resources", ref);
            r.getValue().getOwned()
                .forEach( owned -> {
                    logger.debug("{} has owner references {}, adding new one", owned, owned.getMetadata().getOwnerReferences());
                    owned.getMetadata().getOwnerReferences().add(ref);
                    client.resource(owned).createOrReplace();
                    logger.debug("Updated owner references for {}", owned);
                });

However, the owned resources are not updated when calling createOrReplace. The reason seems to be

DEBUG i.f.k.c.d.i.NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableImpl - Item has not changed. Skipping

This calls

kubernetes-client/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/utils/ResourceCompare.java

Line 35 in 8321522

public static <T> boolean equals(T left, T right) {

, which performs a comparison ignoring the status and metadata fields.

Since my change is metadata-only, it is not applied.

---

As an update, I became aware of the option of using edit().editMetadata() on various resources. The problem here is that there is no generic way of doing it for all resource types, so I have to special-case every resource type that I manage. A generic API would be very much appreciated.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[rombert]

Well @Stale, I'm still interested. Mind keeping this open?

[rohanKanojia]

We have been considering refactoring the behavior of createOrReplace #2292 . I think that would take care of this issue

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[manusa]

createOrReplace methods have been refactored (#2292 - #2372), so this issue should have been fixed.
Please @rombert, could you confirm if your procedure works with the latest release (4.11.1)?

There is a parallel issue (#2454) with an ongoing discussion for createOrReplace behavior. The behavior described in the first comment is related and would stop working again with some of the approaches.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!