kubectl: `kubectl get ... --namespace non-existent` should not exit with 0

Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No.

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): The relevant ones.

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.9", GitCommit:"e6ab4ee54f71e7a403cc733534bab86fd959ecb7", GitTreeState:"clean", BuildDate:"2018-10-16T12:14:47Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.11", GitCommit:"1bfeeb6f212135a22dc787b73e1980e5bccef13d", GitTreeState:"clean", BuildDate:"2018-09-28T21:35:22Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: AWS
OS (e.g. from /etc/os-release): Arch Linux
Kernel (e.g. uname -a): Linux something 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20 22:06:45 UTC 2018 x86_64 GNU/Linux
Install tools:
Others:

What happened:

$ kubectl get pods --namespace non-existent
No resources found.
$ echo $?
0
$

What you expected to happen: I expected kubectl to return anything other than zero when information is requested about resources in a non-existent namespace. The current behavior hides errors and generates bugs in scripts/confusion in interactive use. Fail fast.

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

kubectl get pods --namespace non-existent

Anything else we need to know: No.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 3
Comments: 26 (8 by maintainers)

Most upvoted comments

I agree with the raiser that the behaviour is unexpected: it is surprising that kubectl does not fail when passed a namespace that does not exist. Some colleagues ran into this the other day and wasted some time discussing the current behaviour.

How about making an incompatible change to kubectl in this case to avoid violating the principle of least surprise? If necessary, this change could be scheduled for the next major version of kubectl so that the backward incompatibility would not itself be a surprise. The next major version at the time of writing would presumably be 2.0.

glyn on Feb 11, 2019