Add short name "netpol" for networkpolicies

[xiangpengzhao]

What this PR does / why we need it:
Add short name for networkpolicies in kubectl command for good user experience.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
None

Special notes for your reviewer:
None

Release note:

Add short name "netpol" for networkpolicies

[k8s-ci-robot]

Hi @xiangpengzhao. 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 @k8s-bot 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.

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.

[k8s-github-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

The following people have approved this PR: xiangpengzhao

Needs approval from an approver in each of these OWNERS Files:

• pkg/kubectl/OWNERS

We suggest the following people:
cc @pwittrock
You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

[0xmichalis]

@kubernetes/sig-cli-api-reviews

[0xmichalis]

/release-note

[0xmichalis]

@kubernetes/sig-network-api-reviews

[xiangpengzhao]

Thanks @Kargakis !

Should we also add short names for other resources e.g. clusterrolebindings ?

    * certificatesigningrequests (aka 'csr')
    * clusters (valid only for federation apiservers)
    * clusterrolebindings
    * clusterroles
    * componentstatuses (aka 'cs')
    * configmaps (aka 'cm')
    * daemonsets (aka 'ds')
    * deployments (aka 'deploy')
    * endpoints (aka 'ep')
    * events (aka 'ev')
    * horizontalpodautoscalers (aka 'hpa')
    * ingresses (aka 'ing')
    * jobs
    * limitranges (aka 'limits')
    * namespaces (aka 'ns')
    * networkpolicies (aka 'netpol')
    * nodes (aka 'no')
    * persistentvolumeclaims (aka 'pvc')
    * persistentvolumes (aka 'pv')
    * pods (aka 'po')
    * poddisruptionbudgets (aka 'pdb')
    * podsecuritypolicies (aka 'psp')
    * podtemplates
    * replicasets (aka 'rs')
    * replicationcontrollers (aka 'rc')
    * resourcequotas (aka 'quota')
    * rolebindings
    * roles
    * secrets
    * serviceaccounts (aka 'sa')
    * services (aka 'svc')
    * statefulsets
    * storageclasses
    * thirdpartyresources

[xiangpengzhao]

Oh, just find @gyliu513 posted an issue talking about short names for some other resources #42129

Guangya, are you working on these resources?

[gyliu513]

@xiangpengzhao I think that you can cover all of those issues here, I will try to close my issue if you can cover all of the short names, comments?

Just some proposal for short names

    * statefulsets  (aka 'ss')
    * storageclasses  (aka 'sc')
    * thirdpartyresources  (aka 'tpr')

[0xmichalis]

StatefulSet alias is being discussed in #37099

[thockin]

@smarterclayton There was some concern about new shortcut names - what's the current thinking?

[smarterclayton]

Just that we be very judicious and actually think through how often they will be used, because they become part of the public CLI API (can't change them without breaking scripts). Any time we still a two letter alias, we are preventing ourselves from using it in the future. The bar for getting an alias is inversely proportional to how long it is and how often it is used (we shouldn't add short aliases for rarely used classes).

Most cluster scoped resources aren't going to be accessed that often. We have tab completion, so I'd lean towards no shortcut for rarely accessed resources.

[thockin]

I agree. NetworkPolicy is long and unwieldy and user-facing (namespaced). "np" is pretty short. What about netpol ?

…

On Tue, Feb 28, 2017 at 4:15 PM, Clayton Coleman ***@***.***> wrote: Just that we be very judicious and actually think through how often they will be used, because they become part of the public CLI API (can't change them without breaking scripts). Any time we still a two letter alias, we are preventing ourselves from using it in the future. The bar for getting an alias is inversely proportional to how long it is and how often it is used (we shouldn't add short aliases for rarely used classes). Most cluster scoped resources aren't going to be accessed that often. We have tab completion, so I'd lean towards no shortcut for rarely accessed resources. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#42241 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVH1S5iMK4LTq_oMkCsu5CqDK-sOdks5rhLibgaJpZM4MOQZA> .

[xiangpengzhao]

From a user's perspective, my first reaction is thinking the first letters of the full name of a resource as its shortcut name. If using netpol or something else, users may have to try several times to find the right shortcut:) On the other hand, using np will keep the same style with the most existing shortcuts.

[smarterclayton]

How many users will ever type np often enough to need the shortcut? If we measured the number of times various resources are used, I'd be willing to bet that it's a long tail like: pods replication controllers replica sets deployments services persistent volume claims secrets configmap namespace .... a gap nodes .... a very large gap everything else

…

On Tue, Feb 28, 2017 at 10:27 PM, Peter Zhao ***@***.***> wrote: From a user's perspective, my first reaction is thinking the first letters of the full name of a resource as its shortcut name. If using netpol or something else, users may have to try several times to find the right shortcut:) On the other hand, using np will keep the same style with the most existing shortcuts. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#42241 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_pzkncUFMpIII44UHP0raWbS8gcm1ks5rhOWGgaJpZM4MOQZA> .

[xiangpengzhao]

Reasonable. These resources are indeed not used so often. Then should we close this PR or just merge it and leave other resources without shortcuts as they are now?

[thockin]

I would be OK with netpol, but np is too vague.

…

On Tue, Feb 28, 2017 at 7:48 PM, Peter Zhao ***@***.***> wrote: Reasonable. These resources are indeed not used so often. Then should we close this PR or just merge it and leave other resources without shortcuts as they are now? — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#42241 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVJ_hAsKLZ5sLWgcxQiudDazLu97Xks5rhOqOgaJpZM4MOQZA> .

[xiangpengzhao]

Addressed, but not sure if it's still necessary to merge this according to @smarterclayton 's reason :)

[thockin]

@k8s-bot ok to test

[k8s-reviewable]

This change is 

[thockin]

@k8s-bot gci gce e2e test this

[k8s-ci-robot]

@xiangpengzhao: The following test(s) failed:

Test name	Commit	Details	Rerun command
Jenkins GCE e2e	5daa698	link	@k8s-bot cvm gce e2e test this

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.

[0xmichalis]

@k8s-bot cvm gce e2e test this #43466

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 44862, 42241, 42101, 43181, 44147)