-
Notifications
You must be signed in to change notification settings - Fork 105
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
Use server-side apply patch to update the resolved cross-resource references #623
Conversation
pkg/reconciler/managed/api.go
Outdated
defer existing.GetObjectKind().SetGroupVersionKind(existing.GetObjectKind().GroupVersionKind()) | ||
existing.GetObjectKind().SetGroupVersionKind(schema.GroupVersionKind{}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I couldn't get the reasoning behind these two lines. What happens if we didn't have both?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @turkenh,
The deferred resetting in line 149 is currently not needed and we can remove it. I felt like the function is actually not expected to modify the object existing
which is generally a pointer type and instead of deep copying and modifying the copy, I preferred the much lighter set/reset pattern. Currently, the caller does not use existing
after it calls this function but if we attempt to do so assuming existing
is unmodified, that assumption now holds because we reset the GVK to its original value.
In line 150, we set the GVK to its zero value because in the calculated patch document we need the type meta as in:
{
"apiVersion": "ec2.aws.upbound.io/v1beta1",
"kind": "Subnet",
...
I will leave a comment explaining this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks!
Another idea could be setting those two fields over the generated patch to make it more obvious.
@@ -151,7 +181,11 @@ func (a *APISimpleReferenceResolver) ResolveReferences(ctx context.Context, mg r | |||
return nil | |||
} | |||
|
|||
return errors.Wrap(a.client.Update(ctx, mg), errUpdateManaged) | |||
patch, err := prepareJSONMerge(existing, mg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason why can simply go with a JSON merge patch here is because we don't have a case where a resolved reference is dropped/removed by resolver later. Is this correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, correct. The idea is that we mark the target object list which contains the reference fields with the SSA merge strategy markers. If we use JSON merge patch operation instead of the SSA patch operation, then for example for object lists, the API server cannot properly merge the objects in the list and updates the object as a whole. When both controllers (e.g., the managed reconciler & the XR reconciler) use SSA, then when we specify an SSA merge strategy of map
(together with the list map keys) for the object list, then the API server has a chance to properly merge the list object. For example, when a composition just patches the label selectors for a cross-resource reference, the API server can properly merge only the intended label selector field and not overwrite the reference target fields (e.g., spec.forProvider.vpcConfig[0].subnetIds
in the case of crossplane-contrib/provider-upjet-aws#975) assuming the managed reconciler also uses SSA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, thanks @ulucinar 🙌
pkg/reconciler/managed/api.go
Outdated
defer existing.GetObjectKind().SetGroupVersionKind(existing.GetObjectKind().GroupVersionKind()) | ||
existing.GetObjectKind().SetGroupVersionKind(schema.GroupVersionKind{}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks!
Another idea could be setting those two fields over the generated patch to make it more obvious.
…erences in managed.APISimpleReferenceResolver. Signed-off-by: Alper Rifat Ulucinar <[email protected]>
e9321bc
to
f1be5e6
Compare
I've re-validated this PR using the following packages against
With the SSA changes in the XR reconciler (so that it also uses SSA patch operations for applying the composed resources), the relevant field owners are now as follows:
, where field manager The alternation behavior reported in crossplane-contrib/provider-upjet-aws#975 on
|
Description of your changes
This PR proposes to use server-side apply patch operations in managed.APISimpleReferenceResolver when updating the resolved cross-resource references. This will enable us to address the issue reported in crossplane-contrib/provider-upjet-aws#975 by specifying the SSA merge strategy for the object list
spec.forProvider.vpcConfig
and with the root cause described in detail here.An example patch document computed while updating the resolved VPC ID for the following manifests:
is:
And the resulting managed field object is:
I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
Tested via a custom build of
upbound/provider-aws
with the above manifests and also with the configuration packagesupbound/configuration-aws-eks
andupbound/configuration-aws-network
in the context of crossplane-contrib/provider-upjet-aws#975. The AWS family provider packages used in these tests areindex.docker.io/ulucinar/provider-aws-{ec2, iam, eks}:v0.45.0-c914fe18a92011992e32630ca4d0dba4a8f36242
and the configuration packages areindex.docker.io/ulucinar/configuration-aws-{network, eks}:v0.45.0-c914fe18a92011992e32630ca4d0dba4a8f36242
.