collection .kind, .apiVersion inconsistent between return forms

[cben]

Splitting general .get_plural interface problems from #307. #307 will be only about wrong get_endpoints.kind == "Endpoint" and get_security_context_constraints.kind == "SecurityContextConstraint".

---

Getting a single entity get_foo gives us kind, apiVersion on the resource itself, in all result formats. 👍

Listing multiple get_foos is inconsistent.

• as: :parsed, as: :parsed_symbolized modes give what k8s gives: kind == "FooList" and apiVersion set on the top level, no kind nor apiVersion inside individual resources in items array.
• as: :ros default mode historically tries to help by setting kind == "Foo" (without "List"!). However no apiVersion at all 👎! And again no kind nor apiVersion inside individual resources.

I think kubeclient dropping "List" on top level is now harmful, given the inconsistency between modes, but I'm not sure it's worth breaking compatibility.

I think k8s API behavior of setting kind "FooList" on array but omitting kind "Foo" on individual items is unfriendly, it's just side effect of Go's static typing.

Proposal

I want get_foo to have same shape as get_foos[3]. I want individual items from get_foos to be later directly usable in create/update (as well as exporting to yaml).

• In all modes except :raw, get_foos shall copy apiVersion into each item inside the array.
• In all modes except :raw, get_foos shall set kind in each item inside the array to the individual kind "Foo".
• The top-level behavior will remain.

Are there downsides?
What if someone wants to export get_foos(as: :parsed) as a whole that can be fed to kubectl, the extrenaous kind and apiVersion will cause problems?

Turns out kubectl get foos -o yaml behaves differently from k8s API: it sets a generic kind: List at top level instead of kind: FooList and adds kind and apiVerison inside each element. And kubectl create accepts such list without complaints! And with kind: FooList at top level, it still accepts those. (In fact kubectl 1.10 accepts any other list kind at top level! And oc 3.9 even a non-list kind: Pod at top level. That's probably 1.10 having more validation and not oc/kubectl difference.)

So seems the proposal is in line with the friendlier behavior kubectl already adds on top of the API.

[cben]

ref equivalent python lib issue kubernetes-client/python#745.

• the list kind is not guaranteed to be singular kind + "List" ☹️
• relation between the two not available in discovery info we now get, in principle can be deduced from openapi. not worth it 👎
• but when we make request we already know version & kind, so can just use that!?
  • what about v1beta1 -> v1 and similar normalizations Does API always returns same version that we requested?

These points are all minor, an imperfect fix would still be help 99% cases.