-
Notifications
You must be signed in to change notification settings - Fork 899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"kubectl get" does not behave like its help description says it will. #1596
Comments
This issue is currently awaiting triage. SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the The 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-sigs/prow repository. |
To clarify, you are saying these two cases have the wrong exit code?
And that they should have exit code 1 like this one?
I think what is happening, is in case 1 and 2, you are not requesting a specific pod, so there is no You can see what I mean if you use
vs requesting a specific pod, where you can see the HTTP response is 404 NotFound:
So in case 1 and 2, the command is successfully returning an empty result, and in example 3, the command is failing because it could not find the specific pod you have specified. I think that explains the behavior you are seeing. Whether it is the correct behavior I suppose is open for discussion. The help text from the flag does imply that it only applies when you request a specific object, but maybe it isn't clear enough.
I guess kubectl could print a warning if you use Incidentally, I do think there is a related bug, when you use
In this case, I think the exit code should be 0. |
Right. When reading that help text where it says "the requested object" - I assume "the requested object" means whatever I'm asking to get. And I am requesting an object when I use --selector or just a empty get (now, granted, I could be requesting multiple objects (plural) - but I really don't know what I have - that's why I'm getting them :)
Yes. I think at minimum this is a problem that can easily be corrected - just make the help text more clear. It seems to me reading that help text that the exit code should be non-zero if the requested object (or objects, again I don't know how many there are) does not exist.
If that is the correct expected behavior, that would help also. But, frankly, I think the behavior should change, too. If I ask to get resources, and I get nothing back, exit code should be 0 if |
I think, this KEP kubernetes/enhancements#2551 will propose a standartization with respect to exit code and will fix this. |
What happened:
kubectl get exit code does not match what the
--help
description says will happen.What you expected to happen:
The requested object does not exist (there are no pods). And yet,
--ignore-not-found=false
still results in an exit code of 0. Although--ignore-not-found
does change the stdout behavior (error messages are printed out or not), the exit code doesn't match expectations of the documentation regarding the exit code.How to reproduce it (as minimally and precisely as possible):
See above. Just don't have any pods in the default namespace.
Environment:
kubectl version v1.29.1
The text was updated successfully, but these errors were encountered: