Hi @hysyeah. 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: hysyeah
Once this PR has been reviewed and has the lgtm label, please assign lavalamp for approval. For more information see the Kubernetes Code Review Process.

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

/sig network

This seems like it makes sense... we definitely use that abbreviation in places.
I'm not sure if there are other places that need modifications...

/assign @robscott
who would know if there was some reason we never did this before

I'm not sure if there are other places that need modifications...

no other places that need modifications for shortname

Thanks @hysyeah!

/lgtm
/ok-to-test

LGTM label has been added.

/assign @liggitt @thockin

I thought we had a general moratorium on new shortnames - do I misremember that, @liggitt ?

I don't recall either way, but given they lead to ambiguous outcomes (see #117668) we should maybe discourage adding new official ones?

also, endpointslices doesn't seem egregious to type out

looks like #117535 and #116208 just merged adding more ... if we're unsure about adding new official shortnames, we should revert those until we're sure this is a good direction

Both autocomplete (already exists, used like kubectl get mut<tab> expanding to mutatingwebhookconfigurations...) and locally defined aliases (proposed but not implemented) seem like better solutions than server defined possibly-ambiguous shortnames

cc @hysyeah @kkkkun @wojtek-t @jpbetz @MikeSpreitzer as authors/reviewers on the other PRs adding new shortnames to 1.28 in the last ~week

/hold

Shouldn’t shortnames be under api review? Is the issue the number of types we add, or colliding with ecosystem names? We can certainly have a higher bar for adding a short name,

Names are egregious to type out, i can’t say i’ve typed anything but rs or sts in the last five years. I’m not sure many humans type mutatingwebhookconfigurstion and agree autocomplete handles the non core types. If it’s something you type all the time, a short name is an affordance for humans.

Wish we had data on prevalence of use…

Shouldn’t shortnames be under api review?

they definitely should be since they're API surface, but mechanically weren't because the implementation put the definition in registry packages

Is the issue the number of types we add, or colliding with ecosystem names?

Poor behavior in collision cases, and that shortnames, aliases, and unqualified singular and plural resource names are all in the kubectl fuzzy matching bucket, so adding a CRD with an actual resource type of sts "breaks" the StatefulSet shortname (I think…)

Can we fail to load if we find conflicting shortnames?

I … don't know… #117668 was exploring what to do in ambiguous situations … goals of being user friendly, safe, and compatible are sort of at odds here

The shortnames "eps" does not colliding with other names.
Personally, endpointslice is a resource that need frequent visits, shortname may be more convenient.

Both autocomplete (already exists, used like kubectl get mut<tab> expanding to mutatingwebhookconfigurations...) and locally defined aliases (proposed but not implemented) seem like better solutions than server defined possibly-ambiguous shortnames

cc @hysyeah @kkkkun @wojtek-t @jpbetz @MikeSpreitzer as authors/reviewers on the other PRs adding new shortnames to 1.28 in the last ~week

I agree we should add shortnames to kubectl. We should not change service define and should revert these.

Opened #117993 to undo the just-merged PRs until the path forward is determined, and opened #117995 to capture discovery endpoint output in the api/ package which ensures we don't accidentally change stuff there without API review

The inconsistency of available shortnames ( some {lengthy} types have , but not all) is not good as well. I think we should have clear definition /criteria on this. May be we have such requirement documented somewhere ? 🤔 , I failed to find though.

If we are going to support client-side shortcuts, we should emit a message to that effect or even disallow aliases when running in a script (not 100% sure how to tell - there must be a way). Is there a KEP?

e.g.

$ kubectl get po
<stderr>shortname 'po' resolved to 'pods'
NAME                                                              READY   STATUS      RESTARTS   AGE
iamyouare-5c6cf5d54b-ldvzp                                        1/1     Running     0          13d
iamyouare-5c6cf5d54b-rbqp9                                        1/1     Running     0          13d

$ ./myscript_which_calls_kubectl.sh
<stderr>shortname resolution is not supported in non-interactive mode: 'po'

$ echo $?
99

Do we have a place to document the moratorium?

Do we have a place to document the moratorium?

hmm, not a great place, but https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md didn't have anything about short names or categories, so opened kubernetes/community#7299