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
kubectl: apply --server-side
managed fields migration
#112905
kubectl: apply --server-side
managed fields migration
#112905
Conversation
/hold still doing some manual testing, but sharing this PR to show general approach |
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.
left some comments/discussion points
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'm very happy to see that this known problem is being fixed.
For the release note, can I suggest: For `kubectl`, `--server-side` now migrates ownership of all fields used by client-side-apply to the specified `--fieldmanager`. This prevents fields previously specified using kubectl from being able to live outside of server-side-apply's management and become undeleteable. ? |
/triage accepted |
I would definitely love to have @seans3 review 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.
This PR is in a good place. This PR has a lot of useful comments -- we probably need more. It would be useful to describe the migration process high level somewhere. Something like:
field ownership metadata is stored in three places: server-side-manager
fields, client-side-manager fields, and the last_applied_configuration annotation.
The migration merges the client-side-manager fields into the server-side-manager
fields, and removes the last_applied_annotation (if keepLastApplied is false), so
the only remaining metadata is server-side-manager fields.
Warnings will be fine in the places you've enumerated. There are examples in the apply.go
file showing how to print warnings.
The one area that we'll need to work on is the tests. Current kubectl apply
unit tests are dense, but we'll need to add significant unit tests to ensure proper coverage. As a general rule, we should not have lower unit test coverage numbers after a PR. Including before/after unit test coverage numbers in the PR would be useful. Integration tests will be helpful, but the
focus should be on unit tests. Let's get together to see how to test 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.
Mostly good, thanks, missing test-cmd as discussed offline.
ade7e14
to
4651d35
Compare
/retest |
4651d35
to
4617f3c
Compare
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 have a couple more very minor suggestions, but no concerns. LGTM!
/lgtm
/approve
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.
/approve
I can lgtm once Katrina's comments have been addressed, thanks
// the fields in the given set | ||
// | ||
// If there is an error decoding one of the fieldsets for any reason, it is ignored | ||
// and assumed not to match the query. |
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.
Maybe add a TODO here that we need to account for subresource. And maybe specifically look for empty subresource in the loop
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.
todo was added here:
kubernetes/staging/src/k8s.io/client-go/util/csaupgrade/upgrade.go
Lines 243 to 245 in 26a6e12
//!TODO: some users may want to migrate subresources. | |
// should thread through the args at some point. | |
entry.Subresource == "" && |
4617f3c
to
798efe4
Compare
in discussion with SIG, there is a strong interest in keeping the last-applied-configuration around for a bit longer as other tools transition for of it. This is OK since SSA maintains the annotation on kubectl's behalf on the server-side if it exists migrate client-side-apply fields to SSA when --serverside-side is used kubernetes#107980 kubernetes#108081 kubernetes#107417 kubernetes#112826 add test to make sure only one apply is needed after migration
798efe4
to
ff5e44f
Compare
/retest |
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.
/lgtm
"value": filteredManagers, | ||
}, | ||
{ | ||
// Use "replace" instead of "test" operation so that etcd rejects with |
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.
We don't write this field to etcd so I don't think this explanation is right?
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.
So if we do a json-patch test of resourceVersion, the patch fails to apply without much details. If we set the resourceVersion, then the compare-and-switch etcd performs to write the object fails, and we get a proper 409 conflict. The comment reads fine to me.
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 think it's the "etcd rejects" part that threw me off, I thought it was implying that etcd was checking the field instead of this being passed as metadata on the request.
Maybe open an issue about improving error messages from test directives in patches?
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.
We could improve the error messages, but I don't know if the apiserver will ever interpret/return a failure to apply the patch as a 409 Conflict? Also, applying that patch is done from a third-party dependency.
/approve for client-go |
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.
/approve
for vendor/modules.txt
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alexzielenski, apelisse, BenTheElder, KnVerey, lavalamp The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
@alexzielenski: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
/retest |
Hi @alexzielenski, |
What type of PR is this?
/kind bug
What this PR does / why we need it:
This PR will transparently take ownership of any client-side-apply fields when
--server-side
apply is used. If this is not done, then it will not be possible to remove fields previously used by client-side-apply with server-side-apply (without manually patching managed fields yourself).Previously this change was proposed in a KEP, but during discussion with the SIG we have scoped it down to a bug fix.
Which issue(s) this PR fixes:
addresses issues brought up in the following and likely more bug reports
Fixes #107980
Fixes #108081
Fixes #107417
Fixes #112826
Fixed #99003
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/sig cli
/cc @soltysh @KnVerey @apelisse