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

Resolving references in managed resources can result in incorrectly unsetting previously resolved values. #655

Open
JonathanO opened this issue Jan 29, 2024 · 1 comment
Labels
bug Something isn't working stale

Comments

@JonathanO
Copy link

What happened?

MR for GCP NodePool using clusterSelector and serviceAccountSelector oscillated between having only cluster resolved and having only serviceAccount resolved.

patch, err := prepareJSONMerge(existing, mg)
if err != nil {
return err
}
return errors.Wrap(a.client.Patch(ctx, mg, client.RawPatch(types.ApplyPatchType, patch), client.FieldOwner(fieldOwnerAPISimpleRefResolver), client.ForceOwnership), errPatchManaged)
uses diff to build a patch for server side apply. If only some resolved fields have changed then fields which have not changed will not be in the patch and server side apply will unset them rather than preserving their unchanged values. The next call to reconcile will reverse which are set/unset, and it will never converge on the correct state.

How can we reproduce it?

I encountered this when debugging a fight between provider-gcp and composition functions, which triggered this flip-flopping by unsetting the resolved serviceAccount (but not cluster.)
I have not tested, but think it might happen to a resource that has multiple references if a reference uses ResolvePolicyAlways and the referenced resource changes. Under similar conditions it might also occur using ResolutionPolicyOptional if one of the references initially does not resolve, but later does.

What environment did it happen in?

provider-gcp version: 0.41.1

@JonathanO JonathanO added the bug Something isn't working label Jan 29, 2024
Copy link

github-actions bot commented Sep 3, 2024

Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh will mark this issue as not stale.

@github-actions github-actions bot added the stale label Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working stale
Projects
None yet
Development

No branches or pull requests

1 participant