Shared home for k8s resource type information?

[jpbetz]

For both auger and a declarative application management tool prototype @monopole has been working on, there is a need to depend on the resource type information in the main kubernetes repo:

• k8s.io/kubernetes/pkg/api (for api.Registry and api.Codecs)
• k8s.io/kubernetes/pkg/kubeapiserver/options (which registers the "" group on init)

Currently, the only possible approach is to vendor in all of k8s.io/kubernetes, which is not intended to be vendored.

If kubectl were to be split out into it's own repo (I heard a rumor this might happen) then would it be reasonable to move the api registry and codecs up into a shared common project as well?

See also:

• Find home for shared k8s-specific libraries
• Figure out how to handle code in multiple repos
• Decoupling kubectl from kubernetes

/kind feature

[mbohlool]

cc @caesarxuchao

[bgrant0607]

Is this not https://github.com/kubernetes/api ?

[jpbetz]

@caesarxuchao also suggested I should be able to do everything via https://github.com/kubernetes/api. Here's an example I'm going to try to crib from https://github.com/kubernetes/client-go/blob/076e344c86e52f088b78615f815b245f6d613537/kubernetes/fake/register.go

[jpbetz]

Or maybe I can just use this approach? https://github.com/kubernetes/kubernetes/blob/5adfb24f8f25a0d57eb9a7b158db46f9f46f0d80/pkg/api/legacyscheme/scheme.go Trying it now.

[jpbetz]

@caesarxuchao showed me the correct way to do this: Register all needed types from k8s.io/api like done by client-go's scheme/register.go and use serializer.DirectCodecFactory to create codecs using registered types.

See jpbetz/auger#5 for details.