Finish removing kubectl get all

[raxod502-plaid]

As has been extensively discussed on prior occasions (see kubernetes/kubectl#151), kubectl get all is not recommended, has been removed from documentation, and should be removed.

It appears that the primary reason this has not yet been completed is because the issue was filed against the kubernetes/kubectl issue tracker instead of kubernetes/kubernetes. At the request of the kubectl maintainers in kubernetes/kubectl#1584 (comment), the issue is being copied over to here.

The requested change is that kubectl get all is formally deprecated and eventually removed - or, fixed so that it does what it says it does.

[k8s-ci-robot]

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[sftim]

This is definitely a kubectl issue
/transfer kubectl

[sftim]

Oops, I didn't see that the kubectl maintainers requested tracking it elsewhere.
/transfer kubernetes

[sftim]

/sig architecture
I guess

[sftim]

Are we sure that kubectl couldn't, on its own, first deprecate and then drop support for kubectl get all? Perhaps with some special-case handling?

[sftim]

/retitle Finish removing kubectl get all

[raxod502-plaid]

@brianpursley and @ardaguclu have said in kubernetes/kubectl#1584 that this is not possible in kubectl, so I will leave it to them to describe the rationale.

[brianpursley]

Please, if people haven't already, read the original issue discussion for important context that answers many of the questions being asked.

That issue in k/kubectl was opened a long time ago, and since then (in part due to the issue), kubectl help and docs have been improved, to remove mention of kubectl get all as something that should be used, so it is not like nothing has been done at all from SIG-CLI's side. It's just that this problem is larger than just kubectl.

Are we sure that kubectl couldn't, on its own, first deprecate and then drop support for kubectl get all? Perhaps with some special-case handling?

It's not about kubectl "supporting" kubectl get all... the word "all" is an argument supplied by the user, not a keyword in kubectl. Yes, technically code could be written to detect this argument and block it, but I think it would be unprecedented for kubectl to do something like that, given that "all" is a category that exists in the API.

Besides, the "all" category is visible when you do kubectl api-resources, so it is more that just kubectl get that acknowledges the existence of a category called "all":

~ $ kubectl api-resources --categories=all -o wide
NAME                       SHORTNAMES   APIVERSION       NAMESPACED   KIND                      VERBS                                                        CATEGORIES
pods                       po           v1               true         Pod                       create,delete,deletecollection,get,list,patch,update,watch   all
replicationcontrollers     rc           v1               true         ReplicationController     create,delete,deletecollection,get,list,patch,update,watch   all
services                   svc          v1               true         Service                   create,delete,deletecollection,get,list,patch,update,watch   all
daemonsets                 ds           apps/v1          true         DaemonSet                 create,delete,deletecollection,get,list,patch,update,watch   all
deployments                deploy       apps/v1          true         Deployment                create,delete,deletecollection,get,list,patch,update,watch   all
replicasets                rs           apps/v1          true         ReplicaSet                create,delete,deletecollection,get,list,patch,update,watch   all
statefulsets               sts          apps/v1          true         StatefulSet               create,delete,deletecollection,get,list,patch,update,watch   all
horizontalpodautoscalers   hpa          autoscaling/v2   true         HorizontalPodAutoscaler   create,delete,deletecollection,get,list,patch,update,watch   all
cronjobs                   cj           batch/v1         true         CronJob                   create,delete,deletecollection,get,list,patch,update,watch   all
jobs                                    batch/v1         true         Job                       create,delete,deletecollection,get,list,patch,update,watch   all

Regardless, kubectl isn't the only tool that interacts with the API, so any deprecation or removal, if it is decided to do that, should occur at the API level.