You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MR for GCP NodePool using clusterSelector and serviceAccountSelector oscillated between having only cluster resolved and having only serviceAccount resolved.
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
The text was updated successfully, but these errors were encountered:
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.
What happened?
MR for GCP NodePool using clusterSelector and serviceAccountSelector oscillated between having only cluster resolved and having only serviceAccount resolved.
crossplane-runtime/pkg/reconciler/managed/api.go
Lines 188 to 192 in 7d7a4e9
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
The text was updated successfully, but these errors were encountered: