collection .kind, .apiVersion inconsistent between return forms

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.

Start by tracing the get_foo and get_foos return shapes across the :parsed, :parsed_symbolized, :ros, and :raw modes. Compare the current top-level and items metadata behavior with the proposal, including compatibility concerns for exporting whole lists to kubectl. Done means the agreed non-raw modes consistently add each item's apiVersion and individual kind while preserving the top-level behavior.