Feature Request: Allow openapi references in CRD validation schema

[mtaufen]

Offline chat with @mbohlool: CRD validation schema doesn't currently support references. You can get around this by specifying all of the types inline, but it's extraordinarily verbose (and prone to typos).

[nikhita]

/area custom-resources
/cc @sttts @deads2k @enisoc @colemickens

[sttts]

We were chatting about this idea before. Basically, we need a reference namespace for our API groups, something like apps.k8s.io/v1.StateFulSetSpec (whatever the actual syntax is).

One note about this: the apiextensions apiserver is not coupled to kube-apiserver right now and shouldn't be in the future. How does apiextensionsapiserver know about the specs of the types of other groups? The aggregrator is the only one who knows how to resolve such a reference correctly or at least it know which downstream server to ask.

In other words, getting the information flow right is not so trivial.

[mtaufen]

It should at least be possible for CRDs that are registered with the kube-apiserver, right? Or am I misunderstanding how CRD works?

…

On Thu, Oct 26, 2017 at 3:09 AM, Dr. Stefan Schimanski < ***@***.***> wrote: We were chatting about this idea before. Basically, we need a reference namespace for our API groups, something like apps.k8s.io/v1.StateFulSetSpec (whatever the actual syntax is). One note about this: the apiextensions apiserver is not coupled to kube-apiserver right now and shouldn't be in the future. How does apiextensionsapiserver know about the specs of the types of other groups? The aggregrator is the only one who knows how to resolve such a reference correctly or at least it know which downstream server to ask. In other words, getting the information flow right is not so trivial. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#54579 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA3JwTYEnOBHjCR7QLFQqGm7hK4z-zMLks5swFpZgaJpZM4QGZfO> .

-- Michael Taufen Google SWE

[enisoc]

Could we have apiextensions-apiserver download OpenAPI from kube-apiserver, like kubectl does?

[mbohlool]

/cc @cheftako @mml @lavalamp

[sttts]

Could we have apiextensions-apiserver download OpenAPI from kube-apiserver, like kubectl does?

Yes, something like that which loosely couples those two.

[lavalamp]

I am concerned about giving ourselves really hard problems when we do version updates that drop a previously deprecated field.

[sttts]

I am concerned about giving ourselves really hard problems when we do version updates that drop a previously deprecated field.

We cannot express in our CRD JSON Schema that certain fields do not exist (following the kube API conventions). So a CR cannot become invalid because a deprecated field was dropped. But as we store raw JSON for CRs, those removed fields would continue to exist in old CRs.

[lavalamp]

CRD embeds v1.Pod. (time passes) we deprecate v1.Pod in favor of v2.Pod (...much later...) We remove v1.Pod. Suddenly the entire system loses the ability to interpret the CRD that embedds the v1.Pod object.

[sttts]

At least it won't validate it anymore. Deletion is not a problem.