Remove version from ObjectRef?

[nightkr]

Pros:

• The version is not counted for K8s object identity, Deployment.v1.apps/foo and Deployment.v1beta1.apps/foo refer to the same backend object

Downsides:

• They're not represented the same in the client
• Some APIs (like https://docs.rs/k8s-openapi/0.9.0/k8s_openapi/apimachinery/pkg/apis/meta/v1/struct.OwnerReference.html) inexplicably use versioned references
• We need it if we ever want to allow using it to perform dynamic queries

[clux]

Yeah, the api still require the version field passed in the url, and AFAIK Deployment.v1.apps/foo and Deployment.v1beta1.apps/foo cannot coexist, so there must be some magic in this area.

How does kubectl deal with dynamic queries? I thought it would do it opportunistically by trying the latest versions first.
Have not actually dug into the source for this though.

[nightkr]

AFAIK kubectl downloads the entire API surface and then does its own sorting heurestics. It generally works fine.. until it goes hilariously wrong, like how it would prefer Deployment.v1beta1.extensions over Deployment.v1.apps, all the way until extensions/v1beta1 was finally dropped.

[nightkr]

and AFAIK Deployment.v1.apps/foo and Deployment.v1beta1.apps/foo cannot coexist, so there must be some magic in this area.

Conceptually, K8s stores it internally as Deployment.apps/foo -> (v1, {obj}). The version in the URL is used to either convert it from the stored version to the requested version (on reads), or to convert it to the canonical version (on writes, usually the latest the K8s version knows about).

[clux]

In light of recent PRs and thinking; if we are going to support the runtime features around dynamic objects (like out of the api-resources api), it's only necessary to do the lookup of version once, then fix it for any runtime usage (which will allow users to select how they pick versions in case of ambiguous Deployment versions say).

I think if we get in #385, it will solve the problems with dynamic queries.