cc @deads2k

We don't, asking for a singular resource is an error and should not print
the list.

On Jun 29, 2016, at 2:39 PM, Andy Goldstein notifications@github.com
wrote:

$ kubectl get pod/foo -o yaml
apiVersion: v1
items: []
kind: List
metadata: {}
pods "foo" not found

Prior to #23673 #23673 and
#26686 #26686, we did not
display the empty list; we only displayed the error. I'm guessing we don't
want to display the empty list, do we?

@kubernetes/kubectl https://github.com/orgs/kubernetes/teams/kubectl
@kubernetes/rh-ux https://github.com/orgs/kubernetes/teams/rh-ux
@kubernetes/rh-cluster-infra
https://github.com/orgs/kubernetes/teams/rh-cluster-infra @smarterclayton
https://github.com/smarterclayton @liggitt https://github.com/liggitt

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#28243, or mute the thread
https://github.com/notifications/unsubscribe/ABG_p7dVNXmxYfSc3QrQszTKpmerDMiqks5qQuYLgaJpZM4JBl_I
.

I have a local change that does this:

vagrant@f24:~/go/src/k8s.io/kubernetes (master) k get pod/foo -o yaml
Error from server: pods "foo" not found

vagrant@f24:~/go/src/k8s.io/kubernetes (master) k get pod/foo pod/bar -o yaml
apiVersion: v1
items: []
kind: List
metadata: {}
[pods "foo" not found, pods "bar" not found]

It still seems a little strange, if you ask me... Also, if you mix getting a pod that does exist with one that does not:

vagrant@f24:~/go/src/k8s.io/kubernetes (master) k get pod/date pod/no -a
NAME      READY     STATUS      RESTARTS   AGE
date      0/1       Completed   0          58s
pods "no" not found

vagrant@f24:~/go/src/k8s.io/kubernetes (master) echo $?
1

Is this acceptable?

IMO it's more natural to have no list for k get pod/foo pod/bar -o yaml.

Also the error message "pods not found" is strange.

Yeah, I think if you ask for a list of things and they're all 404, it probably makes sense to return no list. What about in my 2nd example, where you ask for 2 pods and it can only find 1?

Agreed about the error message, but let's leave that oddity for another issue if that's ok? 😄

It still seems a little strange, if you ask me...

I think its a little weird that asking for one resource by name and getting no results is different than asking for two resources by name and getting no results.

For the text output the behavior is certainly fine to print out 1 pod + 1 error.

An alternative to get it consistent: print an empty yaml list also for k get pod/foo -o yaml

An alternative to get it consistent: print an empty yaml list also for k get pod/foo -o yaml

That's what master currently does

Oh right, that's what this issue is all about :)

An alternative to get it consistent: print an empty yaml list also for k get pod/foo -o yaml

You could also go the other way and have no list output if you requested single resources that all 404.

Truth be told the empty list plus error plus non-zero return code doesn't bother me.

I think printing empty list when one resource was requested is a bad thing. It basically returns different data type than requested by user. In the one case it is a single resource and in the other case it is a list. A script can certainly handle that but it looks ugly and inconsistent to me.
Another thing is that returning different exit code depending on data format requested is also weird and can confuse scripts.
Lastly this is a breaking change for scripts from previous version. I think such changes need to be justified by some tangible improvements to user experience. And I don't see any improvement by this change in behavior.

IMO if specific resource is explicitly requested by user and is not found (regardless if user requested 2, 3 or more resources), then command should return an error exit code and a string of some sort containing "not found" (as before). Now if you list by label, it is perfectly fine to return success with empty list. That's like ls will list files in a directory and will return 0 when none files are in there. But if you do ls nonhere it will return an error. Also with multiple items:

$ ls pohvali asdff
ls: cannot access asdff: No such file or directory
pohvali
$ echo $?
2

-- my two cents

cc @metral @janetkuo @erictune

There are currently 2 open PR's that resolve this issue: #28251 and #28294, where the latter has additional tests for test-cmd.sh.

Think we're just waiting on someone more informed to advise which route is preferred, and then merging that PR in

+1

"singular" is the signal that the user asked for a single item, so we should return an error (instead of displaying empty lists).

kubectl get pods/foo -> singular, error
kubectl get pods -> not singular, no error
kubectl get -f pod_with_one_item.yaml -> singular, error
kubectl get -f directory -> not singular
kubectl get -f list_with_many_items -> not singular

@smarterclayton , besides singular, we need to also account for "specific". I liked most the idea to be like ls. Show a list of items that were found but print on stderr error messages and return non-zero status.