feat: add isSameResource on HasMetadata

[metacosm]

Description

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[manusa]

Should apiVersion be checked too? (e.g. two resources with same kind but different apiVersion v1beta1 vs. v1alpha1 (or a real legacy case such as apps/v1 vs extensions/v1beta1 Deployment) would be considered the same)

[metacosm]

The first implementation was doing that and then I read in the Kube docs that an object's identity shouldn't take the API version into consideration… cf https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

We could have an option to also check the API version, if we think it's interesting to do so.

Another question I had, was with respect to the UID… I'm not sure about how it's used and whether or not it should factor in this function.

[csviri]

Yes, I was just going to ask that, if UID is present on both resources on that case probably would be enough to check that.

[csviri]

API version is tricky, since there should be a conversion hook, and there is always just one stored version, not sure if after the conversion it preserves UID, would be worth to check.
Is is a matter of definition too, what we call "same resource".

[csviri]

I would be a little cautious introducing notions like this which are not generic kubernetes terms

[metacosm]

The question I had wrt to UID is that I was wondering if it's possible for a logical resource which would be recreated with the same UID (since it's supposed to be the same resource) could end up with a different name and namespace? I don't really have much experience dealing with UIDs so I'm not too sure if that's a valid use case or not…

[csviri]

The question I had wrt to UID is that I was wondering if it's possible for a logical resource which would be recreated with the same UID (since it's supposed to be the same resource) could end up with a different name and namespace?

Here we are comparing two resources where both should live on the server (or at least live close in time), theoretically this could happen, but I don't think we should care. The probability of UID collision is already:

For example, the number of random version 4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion.
And we are talking about a short period of time this to happen.

If that happens I will eat my red hat :)

[manusa]

did you manage to check the UID preservation after the conversion hook is applied?
From my side I'm happy to merge this since you folks (and downstream users of JOSDK) are probably the ones who will be consuming it.