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
Improve kubectl field manager names for clearer conflicts #88885
Improve kubectl field manager names for clearer conflicts #88885
Conversation
/sig cli |
How does this look? We would add |
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.
All of this looks great to me (I haven't looked in details). I think this is the right approach, but I suspect we should get approval of sig-cli, maybe through a apply kep update?
@@ -223,6 +223,13 @@ func (o *ApplyOptions) Complete(f cmdutil.Factory, cmd *cobra.Command) error { | |||
} | |||
o.DryRunVerifier = resource.NewDryRunVerifier(o.DynamicClient, discoveryClient) | |||
o.FieldManager = cmdutil.GetFieldManagerFlag(cmd) | |||
if !cmd.Flag("field-manager").Changed { | |||
if o.ServerSideApply { | |||
o.FieldManager = "kubectl-server-side-apply" |
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.
does changing the default mean the same kubectl serverside apply operation in subsequent releases would report a conflict with itself?
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 it does, that's a good point. We probably can't change the "server-side apply" default manager now, kubectl
is still a fine name though.
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.
Ohh I see. Updated to kubectl
and added a note about why
de80201
to
0d5af2b
Compare
Okay i'll make a small update to the KEP so we can get feedback from CLI too, and proceed to inventory all of the commands that need to be updated |
96250e3
to
3435626
Compare
f97e078
to
d035f84
Compare
e1c2f12
to
360c348
Compare
/lgtm |
/retest |
1 similar comment
/retest |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: julianvmodesto, seans3 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 |
/retest Review the full test history for this PR. Silence the bot with an |
3 similar comments
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
Looks like a flake: #91075 /retest |
/retest Review the full test history for this PR. Silence the bot with an |
3 similar comments
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
@julianvmodesto: 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 Review the full test history for this PR. Silence the bot with an |
remove unnecessary function after PR #88885 merged
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
This change improves the kubectl field manager names for clearer conflicts, instead of the default
.manager=kubectl
.When an object is managed by server-side apply and has field managers, any
kubectl
commands will use the same field manager:kubectl
. When there is a conflict, then this is confusing because different operations will have the same field manager name. Instead, we can set kubectl subcommands as the field manager name e.g. the manager forkubectl annotate
should bekubectl-annotate
. This provides a better conflict hint.For kubectl commands, this change sets the field manager accordingly:
kubectl apply
has.manager=kubectl-client-side-apply
kubectl apply --server-side
has.manager=kubectl
(remainskubectl
instead ofkubectl-server-side-apply
for backwards compatibility)kubectl annotate
has.manager=kubectl-annotate
List of kubectl subcommands updated:
Which issue(s) this PR fixes:
Related to #80916
Does this PR introduce a user-facing change?: