results of list API calls have no kind or apiversion set for items

[juliantaylor]

list calls do not set the kind of api version of the items:

# works
In [14]: client.list_service_for_all_namespaces().kind
Out[14]: 'ServiceList'

# works
In [18]: client.read_namespaced_service(namespace=namespace, name=name).kind
Out[18]: 'Service'

# wrong
In [16]: type(client.list_service_for_all_namespaces().items[0].kind)
Out[16]: NoneType

I suspect this might be caused by #744 but I am not sure how the de-serialization exactly works.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.

[cben]

To add to the observation on #819 (comment) that list kind might not always be item's kind + "List":

Indeed, CRDs have separate field ListKind:

$ kubectl explain crd.spec.names
KIND:     CustomResourceDefinition
VERSION:  apiextensions.k8s.io/v1beta1
...
   kind	<string> -required-
     Kind is the serialized kind of the resource. It is normally CamelCase and
     singular.

   listKind	<string>
     ListKind is the serialized kind of the list for this resource. Defaults to
     <kind>List.
...

It's optional, and I don't know why anyone should want to override it. The CRDs I've see that do set it all followed the "FooList" convention, but there are probably some out there that deviate from it?

---

In theory, the relation between item kind and list kind can be extracted from swagger.json / openapi.json, following $ref links for the type of items property, mapping both through "x-kubernetes-group-version-kind":

...
    "io.k8s.api.core.v1.Pod": {
      "description": "Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts.",
...
      "x-kubernetes-group-version-kind": [
        {
          "group": "",
          "kind": "Pod",
          "version": "v1"
        }
      ]
    },
...
    "io.k8s.api.core.v1.PodList": {
      "description": "PodList is a list of Pods.",
...
      "properties": {
...
        "items": {
          "description": "List of pods. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md",
          "type": "array",
          "items": {
            "$ref": "#/definitions/io.k8s.api.core.v1.Pod"
          }
        },
...
      "x-kubernetes-group-version-kind": [
        {
          "group": "",
          "kind": "PodList",
          "version": "v1"
        }
      ]
    },

IIUC the openapi is autogenerated, so I hard to say how reliable this inference would be into the future, but same structure is present in oldest and newest samples I have at hand:
https://cben.github.io/kubernetes-discovery-samples/kubernetes-v1.7.0/swagger.json and https://cben.github.io/kubernetes-discovery-samples/kubernetes-v1.15.0/openapi/v2/index.json 🤷

[cben]

Personally I don't feel implementing this openapi inference is worth the trouble.

However, it's interesting that kubectl get -o json foos does hide this API ugliness from users: all lists print out kind: List at top level, and it inserts correct kind and apiVersion into each element under items.