Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SetClaimReference must pass to underlying object just claimRef allowed fields #552

Merged
merged 1 commit into from
Oct 10, 2023

Conversation

pedjak
Copy link
Contributor

@pedjak pedjak commented Sep 20, 2023

Description of your changes

spec.claimRef schema is just subset of corev1.ObjectReference, and hence SetClaimReference might get a reference that have more fields set, e.g. UID. The fields that do not exist in claimRef schema must be not set on the underlying object, otherwise K8s API server complains about non-existing field when client sends a patch request.

  • Introduced claim.Reference type that corresponds to spec.claimRef schema.
  • composite.SetClaimReference signature changed to accept an instance of claim.Reference
  • appropriate tests updated/new tests added

Discovered while working on crossplane/crossplane#4047

I have:

  • Read and followed Crossplane's contribution process.
  • Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

Adjusted unit test to catch regression.

@pedjak pedjak requested review from a team as code owners September 20, 2023 12:33
@pedjak pedjak requested review from bobh66 and lsviben September 20, 2023 12:33
@negz
Copy link
Member

negz commented Sep 20, 2023

@pedjak Do you think it would be possible to switch to using a type without the extraneous fields? That seems ideal to me, since it would also update our claim OpenAPI schemas to better communicate that we don't actually pay any attention to all the extraneous fields (e.g. UID). In some places we've started defining our own types instead of ObjectReference, per #49.

Namespace: ref.Namespace,
Name: ref.Name,
}
_ = fieldpath.Pave(c.Object).SetValue("spec.claimRef", claimRef)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm.

Just curious, why do we use a type if it is not supported?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also wonder if this method needs to live in crossplane-runtime at all, because it is only consumed in crossplane?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a different question. What @negz and I mean is that corev1.ObjectReference is the wrong type. We should have a ClaimReference type instead that only has the fields that are allowed to be set.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you change this, i.e. introduce that type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can, if we are ok with having breaking API change? @negz ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does anything actually write (or read) the UID field in a claimRef today? If no, I feel fine making the change since while technically breaking at the API level it would functionally be a no-op.

@pedjak
Copy link
Contributor Author

pedjak commented Sep 21, 2023

Do you think it would be possible to switch to using a type without the extraneous fields? That seems ideal to me, since it would also update our claim OpenAPI schemas to better communicate that we don't actually pay any attention to all the extraneous fields (e.g. UID). In some places we've started defining our own types instead of ObjectReference, per

Not sure if I got it right: would you like to change the signature of SetClaimReference? That would be a breaking API change, not sure what would be the blast radius?

IMHO, it is quite alright to pass ObjectReference and the method take out of it what is needed to craft claim reference valid according to the schema.

@sttts
Copy link
Contributor

sttts commented Oct 6, 2023

That would be a breaking API change, not sure what would be the blast radius?

Blast radius is minimal:

  1. https://grep.app/search?q=SetClaimReference
  2. the change is safe, i.e. compilation breaks. So ppl will notice.

@pedjak
Copy link
Contributor Author

pedjak commented Oct 9, 2023

Blast radius is minimal:

@sttts @negz I have updated PR, ptal.

…Reference

`spec.claimRef` schema is just subset of corev1.ObjectReference, and hence
`SetClaimReference` might get a reference that have more fields set, e.g. UID.
The fields that do not exist in claimRef schema must be not set on the underlying object,
otherwise K8s API server complains about non-existing field when client sends a patch request.

* Introduced `claim.Reference` type that corresponds to `spec.claimRef` schema.
* `composite.SetClaimReference` signature changed to accept an instance of `claim.Reference`
* appropriate tests updated/new tests added

Signed-off-by: Predrag Knezevic <[email protected]>
@turkenh turkenh merged commit a8f7557 into crossplane:master Oct 10, 2023
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants