Hi @julianvmodesto. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: julianvmodesto
To complete the pull request process, please assign wojtek-t
You can assign the PR to them by writing /assign @wojtek-t in a comment when ready.

The full list of commands accepted by this bot can be found here.

This is a good start, but I think it might be difficult to implement the necessary logic to update the managedfields for scale here, since the code for parsing it and encoding it is defined in k8s.io/apiserver/pkg/endpoints/handlers/fieldmanager/internal.

I had an idea for how to get around that, let me know if you think it makes sense. The idea is to create a "scale fieldmanager" (that only understands how to update the scale field's ownership of an object), in the k8s.io/apiserver/.../fieldmanager package, and add it to the scale request scope, so it gets passed into ScaleRest.Update by the scale subresource handler automatically as a transformer for the updatedObjectInfo.

To wire this from the subresource to the main resource, autoscaling.v1/Scale already has a metadata field which includes managedFields. We could use that to adjust the managedfields, by modifying scaleFromDeployment to populate that field, then the transformer to the updatedObjectInfo which we passed in earlier would update the ownership for us, and we just need to make sure we also copy back the value from the scale's managedFields into the deployment object.

The "scale fieldmanager" would operate on objects of type autoscaling.v1/Scale, but with managedFields representing field management on the underlying resource. Then, it just needs to know what fieldpath in the underlying resource corresponds to Scale.spec.replicas, in deployment's case it would be the same fieldpath, but I think CRD can define the path themselves, so we would have to construct the scale field manager with that path as an argument.

Another option is to pass in a Deployment FieldManager into the sub-update as a transformer here

@jennybuckley oh nice! Thank you, this makes sense! I'll give it a shot

@jennybuckley would your suggestion mean, that we would have to have a fieldManager for every subresource?