`kubectl label`: Inconsistent messaging when both adding and removing labels

[KnVerey]

What happened:

What you expected to happen: kubectl label should produce a consistent, accurate message when labels are both removed and added at the same time (maybe just "labels modified" for simplicity?).

How to reproduce it (as minimally and precisely as possible):

$ kubectl label pod mypod a=b aa=bb
pod/mypod labeled

$ kubectl label pod mypod a- ee=ff
pod/mypod labeled # because the new label is textually longer

$ kubectl label pod mypod aa- e=f # same operations as above
pod/mypod unlabeled # different message, because the old label is textually longer

Anything else we need to know?: The problem seems to be the use of a length comparison in this function: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kubectl/pkg/cmd/label/label.go#L399-L408. That might be reliable if labels could only be added OR removed by an operation, but as in the examples above, both are possible at once.

Environment:

• Kubernetes client and server versions (use kubectl version): Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.2", GitCommit:"5835544ca568b757a8ecae5c153f317e5736700e", GitTreeState:"clean", BuildDate:"2022-09-21T14:25:45Z", GoVersion:"go1.19.1", Compiler:"gc", Platform:"darwin/arm64"}
• Cloud provider or hardware configuration: n/a
• OS (e.g: cat /etc/os-release): n/a

/sig cli

Fixed by https://github.com/kubernetes/kubernetes/pull/110124

[ardaguclu]

Although there is no direct relation but to distinguish label/unlabel message also causing this issue https://github.com/kubernetes/kubectl/issues/1265 as a symptom. If we decide to just say modified, this issue will also be fixed.

[astraw99]

Got it, will fix it in PR https://github.com/kubernetes/kubernetes/pull/110124

[eddiezane]

/triage accepted /priority backlog /assign @astraw99

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[astraw99]

/remove-lifecycle stale

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[TessaIO]

/assign