kubectl get broken for list

[mengqiy]

kubectl get -o yaml|json is broken for list.

How to reproduce:
Create multiple resource from list: kubectl create -f https://raw.githubusercontent.com/kubernetes/kubernetes/master/hack/testdata/multi-resource-list.json.

Get the resources back: kubectl get -o yaml -f https://raw.githubusercontent.com/kubernetes/kubernetes/master/hack/testdata/multi-resource-list.json

Output:

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: 2016-12-16T22:09:53Z
  labels:
    app: mock
  name: mock
  namespace: default
  resourceVersion: "387943"
  selfLink: /api/v1/namespaces/default/services/mock
  uid: 5edec4bb-c3dc-11e6-aa89-42010a800002
spec:
  clusterIP: 10.0.160.121
  ports:
  - port: 99
    protocol: TCP
    targetPort: 9949
  selector:
    app: mock
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

Only the first resource get printed out.

@kubernetes/kubectl @kubernetes/sig-cli-misc

[mengqiy]

@fabianofranz maybe we need to include this in #38768?

[adohe-zz]

@ymqytw what't the get response? I mean we really get all resources or just issue with printer.

[mengqiy]

@adohe I guess it's printer's issue. But I'm not sure how printer works for list of resources.
We get all the resources. There are 2 GET requests:
api/v1/namespaces/default/services/mock
api/v1/namespaces/default/replicationcontrollers/mock
But the printer only prints out service.

[fabianofranz]

maybe we need to include this in #38768?

Done.

[smarterclayton]

Is this also broken in 1.5, i.e. a regression?

…

On Mon, Dec 19, 2016 at 2:33 PM, Fabiano Franz ***@***.***> wrote: maybe we need to include this in #38768 <#38768>? Done. — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#38907 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_p7qUdxqFMvpNQuTG5kJ9O_C3yFNrks5rJtwXgaJpZM4LPpUo> .

[mengqiy]

Is this also broken in 1.5, i.e. a regression?

Yes, it is also broke in 1.5.

[smarterclayton]

Setting priority and adding cherry pick candidate. This would break people using scripting.

[smarterclayton]

Can someone take ownership to fixing this and getting it into the 1.5.x track?

[adohe-zz]

@smarterclayton I would fix this today.

[adohe-zz]

@kubernetes/sig-cli-misc the root cause is: we retrieve a list from server, and then we flatten the list , get multiple Info, but singular here is true, so we just print the first object.

[ncdc]

Looks like this behavior was changed in #36085. I think the fix is to check len(infos) instead of looking at singular, as singular is going to report true when you do kubectl get -f <file> (and it looks like that hasn't changed from before).

[smarterclayton]

And add a test so it doesn't break again! :)

…

On Tue, Dec 20, 2016 at 12:11 PM, Andy Goldstein ***@***.***> wrote: Looks like this behavior was changed in #36085 <#36085>. I think the fix is to check len(infos) instead of looking at singular, as singular is going to report true when you do kubectl get -f <file> (and it looks like that hasn't changed from before). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#38907 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABG_pxwIXAqepc5TVhN8PRqIgmDE2iG6ks5rKAw4gaJpZM4LPpUo> .

[ncdc]

I can fix this if you would like me to, @adohe?

[ncdc]

My suggestion above breaks other tests. Trying to figure out what's up.

[ncdc]

Ah I see what it is. We still need to check singular and go into the list code path if it's !singular || len(infos) > 1

[adohe-zz]

@ncdc thanks very much :)