Thanks for the report. I agree kind should always be present. Lists have other inconsistencies that need to be fixed, also -- see #2740.

As for why we need kind, we need it for the same reasons as apiVersion (#3000) -- serialized representations, and in cases where we provide GET/WATCH of multiple kinds of objects.

Yeah, we made a decision a while ago not to fill in redundant 'kind'/'apiVersion' fields, but we can revisit that.

Once data is marshalled into a go struct, the kind/apiVersion fields are redundant with the type information, so we have the rule that they're always set on the wire and unset in memory. This rule wouldn't (necessarily) make sense for dynamically typed languages.

A consequence of that is that we decided not to recursively set (on the wire) the kind fields on embedded objects of known types, since once you know the enclosing type, you can deduce the other types. But I can see how this would be awkward for non-go clients.

Types with sub-objects that are determined at runtime (see the generic List type that @smarterclayton recently added) are different. For those, we emit version/kind for each sub object, since you cannot deduce this information from the enclosing type.

I can think about a general solution to this if it's important. It'll probably be a bit of a pain to change, though.

@lavalamp thanks for the long explanation.
Consider a ruby client or a Java client consuming the api and converting the json response to objects - it will have to have some "if"s to populate the kind attribute or omit it because otherwise the objects won't be symmetrical, and it can also make some noise when comparing 2 objects. So it's solve-able on client sides, but I'd say it's better to solve it once on server side for all clients.

This would also be fixed by not returning the full bodies of the objects on LIST. :-)

I like that fix best of all!

@bgrant0607 this can be problematic for clients because in some cases they'll need afterwards to go to server for each entity again, and that's not effective.
What are you planning not to return in LIST? which part of entities?
BTW this could also be solved by providing support with a flag that clients pass - by default you could pass shallow entities, and with that flag - full entities.

Yeah, making full objects/list only configurable + adding kind/apiVersion deeply is probably best.

@lavalamp , on the same topic - what's the expectation from clients creating (POST) a new object - must they fill 'kind' attribute? I mean it's possible to pass it, but not very standard since you already create it on some resource (/services).
I tried creating without this property and it works fine, but it's important to understand what's the 'formal' expectation.

Yes, the server can deduce kind & apiVersion, so they're not required for POSTs or PUTs.

Specifying an incorrect kind for the URL you're using will cause an error. Specifying a different version than is in your URL will cause the server to convert your request appropriately (liberal in what it accepts).

Actually, with the pending renames to minion you can pass both kind "node" and kind "minion" to the v1beta1/2 api endpoints. This is to make backwards compatibility easier.

On Dec 21, 2014, at 3:28 PM, Daniel Smith notifications@github.com wrote:

Yes, the server can deduce kind & apiVersion, so they're not required for POSTs or PUTs.

Specifying an incorrect kind for the URL you're using will cause an error. Specifying a different version than is in your URL will cause the server to convert your request appropriately (liberal in what it accepts).

—
Reply to this email directly or view it on GitHub.

Oh, true-- I forgot about that exception.

sorry wrong comment, pls ignore this last comment in this thread

Here's how this should be done.

The current rule is "kind & version are set on disk and blank in memory".

So we will change the rule to "kind & version are clear in unversioned structs, but set in versioned structs". Then we'll change the conversion routines that copy TypeMeta objects. They can look at the conversion.Scope to see what exactly they're copying to/from, and they can set the kind & apiVersion fields accordingly. (conversion.Scope should already support this, I'm pretty sure I added it recently.)

Finally, we can remove all the code in conversion that is currently responsible for setting these values before serialization and clearing them afterwards.

This should have the net effect of making serializations faster. We'll also possibly have to update tests; we could expand the api.Semantic's equality functions if that makes sense.

We'd want to nuke TypeMeta from internal types, correct?

----- Original Message -----

Here's how this should be done.

The current rule is "kind & version are set on disk and blank in memory".

So we will change the rule to "kind & version are clear in unversioned
structs, but set in versioned structs". Then we'll change the conversion
routines that copy TypeMeta objects. They can look at the conversion.Scope
to see what exactly they're copying to/from, and they can set the kind &
apiVersion fields accordingly. (conversion.Scope should already support
this, I'm pretty sure I added it recently.)

Finally, we can remove all the code in conversion that is currently
responsible for setting these values before serialization and clearing them
afterwards.

This should have the net effect of making serializations faster. We'll also
possibly have to update tests; we could expand the api.Semantic's equality
functions if that makes sense.

---

Reply to this email directly or view it on GitHub:
#3030 (comment)

Yes, it's not needed on internal types.

Not having the kind on each item in the list makes it difficult to write a UI to generically describe objects (the kind attr is required input for something like https://github.com/kubernetes-ui/object-describer/blob/master/object-describer.js#L42-L53)

@jwforres fyi

PR to set the kind and apiversion would be welcome. Sort of related: #3000, #6439

cc @caesarxuchao, since it's related to the other apiVersion/kind issues

thanks!
/assign @leilajal @Jefftree

Summarizing this issue from the comments above, the list API omits apiVersion and kind from the returned items. We should populate those fields for external types.

It looks like there have been attempts at fixing this:

• WIP - set apiVersion/kind in list items #80618
• [WIP] add apiversion and kind to list subitems #63972

haven't really looked too deep into the PRs, but the main thing I see is that the performance impact needs to be verified and we need consensus on the approach.

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

This issue still exists. Is it a problem we actually intend to solve?

/triage accepted