Skip to content

Conversation

@sergenyalcin
Copy link
Member

@sergenyalcin sergenyalcin commented May 5, 2025

Description of your changes

Fixes #103

This PR uses the reintroduced crossplane-runtime helper functions: crossplane/crossplane-runtime#833.

Since the behavior change in the ptr.Deref, we considered reusing them. Details are in the issue.

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

Tested in the provider-upjet-gcp and provider-upjet-azuread locally.

Signed-off-by: Sergen Yalçın <yalcinsergen97@gmail.com>
Signed-off-by: Sergen Yalçın <yalcinsergen97@gmail.com>
@sergenyalcin sergenyalcin changed the title Handle empty ResolvedValue as nil in reference resolvers and fix *float64 resolver generation Handle empty ResolvedValue as nil in reference resolvers and fix *float64 resolver generation May 5, 2025
Signed-off-by: Sergen Yalçın <yalcinsergen97@gmail.com>
@haarchri
Copy link
Member

haarchri commented May 6, 2025

for the second issue xref: #102 ?

Comment on lines 157 to 161
if v := rsp.ResolvedValue; v != "" {
mg.Spec.ForProvider.SecurityGroupID = ptr.To(v)
} else {
mg.Spec.ForProvider.SecurityGroupID = nil
}
Copy link
Member

Choose a reason for hiding this comment

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

I'd like to avoid all these if else clauses. Could we instead reintroduce ToPtrValue?

I suggested we remove it because I thought it did the same thing as ptr.To. Given I was wrong, I'd rather keep it than inline its logic here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, @negz for your review.

That would be better, too. Actually, I would prefer to keep the old function usage rather than adding this complexity to reference resolvers. However, I didn't want to bring this up again, as these functions have been removed there, and I don't think they are intended to be used. Instead, this is how I solved it in its current form.

If we are going to reuse this ToPtrValue, I'm okay with that too, and that would be even better. It is safer and makes more sense than carrying this logic to resolvers.

In this context, would you recommend reintroducing these functions in crossplane-runtime or in the crossplane-tools repo?

Copy link
Member

Choose a reason for hiding this comment

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

I'd prefer to re-add them to runtime. I don't think we use Crossplane-tools as a library anywhere, right? Instead it's just CLI utils that generate code.

At this point it may make sense to just revert crossplane/crossplane-runtime#780. It sounds like the premise of that PR was flawed: I thought our library of pointer helpers did the same thing as the k8s.io/ptr package, but they didn't. So there's value in having our own package.

Disclaimer: I'm stretched extremely thin right now and don't have much time to double check my understanding. My guidance is:

  • I'd prefer us to not have code in crossplane-runtime if there's an upstream alternative that does the same thing
  • It's fine to have code in crossplane-runtime that does something useful to us

If it seems to you that the pointer utils we deleted satisfy the above constraints, please re-add them. 😄

Copy link
Member Author

Choose a reason for hiding this comment

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

Reverted this crossplane/crossplane-runtime#780 and reused in here.

Signed-off-by: Sergen Yalçın <yalcinsergen97@gmail.com>
Signed-off-by: Sergen Yalçın <yalcinsergen97@gmail.com>
@cristiGuranIonos
Copy link

Can a fix be merged for this?

Copy link
Collaborator

@ulucinar ulucinar left a comment

Choose a reason for hiding this comment

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

Hi @sergenyalcin,
This PR looks good to me. There are a couple of points worth mentioning:

  • In the package pkg/convert, we have a bunch of deprecated conversion functions in favor of those in k8s.io/utils/ptr. Because their behaviors differ, we may consider to remove the deprecation notices also. But I propose we do so in a follow-up PR.
  • Looking at the comment in that package. my understanding is that it has been added as the package to import for the APIs. If this was the intent, we are still using the re-added utility functions from crossplane-runtime. Because this was already the old behavior, I think this is fine for this PR. We may follow-up if this is really the intent.
  • Some "new" providers may have used the recent versions of crossplane-tools and may be depending on the behavior of the k8s.io/utils/ptr package. And we are reverting back the behavior.

ClientImport: ClientAlias,
ConvertImport: ConvertAlias,
ReferenceImport: ReferenceAlias,
PtrAlias: PtrImport,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Interesting. Shouldn't this have been PtrImport: PtrAlias (key & value reversed) in the first place? Looks like the function expects a map where keys are imports, not aliases?

@ulucinar ulucinar changed the title Handle empty ResolvedValue as nil in reference resolvers and fix *float64 resolver generation Revert back to using cross-resource reference utilities from crossplane-runtime Jun 3, 2025
@ulucinar ulucinar merged commit 889cfb1 into crossplane:master Jun 3, 2025
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.

Regression in reference field resolution with ptr.To() causing empty strings to be set instead of nil

5 participants