Kubebuilder: Generate openapi spec for CRD objects

[gclawes]

Provide a way to generate OpenAPI specs for the CRDs generated by kubebuilder. It would be useful to be able to generate API libraries for CRD objects in languages other than go.

A specific use case is where the controller for a CRD is written in go, but tools that generate Custom Resource configurations are written in other languages that OpenAPI can generate libraries for (Python, Java, Ruby, Bash, etc). This is especially useful when such applications are already using the OpenAPI-generated kubernetes libraries (kubernetes-client/*).

This issue was started based on a discussion in #1129

This does not require a specific kubernetes version.

/kind feature

[DirectXMan12]

That's what controller-tools already generates OpenAPI data for CRDs as part of generating the CRD validation schema. Is that not sufficient?

[gclawes]

I haven't been able to find any documentation on that, could you point me in the right direction?

[RedbackThomson]

That's what controller-tools _already_ generates OpenAPI data for CRDs as part of generating the CRD validation schema. Is that not sufficient?

I see the OpenAPI embedded as validation. Are you suggesting this is a fully functional OpenAPI spec itself? Is there any way to output these into its own spec file rather than having to extract it?

[DirectXMan12]

I see the OpenAPI embedded as validation. Are you suggesting this is a fully functional OpenAPI spec itself?

Yes, more or less. The Kubernetes API server is free to change it in ways that we don't have control over/can't (e.g. it substitutes the top-level ObjectMeta for the current server's ObjectMeta), but the validation spec is a valid and (almost) complete OpenAPI spec.

Is there any way to output these into its own spec file rather than having to extract it?

As of now, there's no way to generate it into a separate file, but we could add that. In the mean time (if this is really pressing), you should be able to consume that part of controller-tools as a library.

However, you're slightly better off pulling it from the live API server if you're really concerned with full correctness (see above).

[RedbackThomson]

As of now, there's no way to generate it into a separate file, but we could add that

I could see this being a very valuable feature for operator clients who intend for others to consume their CRDs from third-party clients (or wrappers). It's not pressing for us at the moment, but would love to see this on the road map at some point.

you're _slightly_ better off pulling it from the live API server

We would like to consume it at compile-time and also to produce CRD documentation, so sadly this isn't an option.

[gclawes]

I could see this being a very valuable feature for operator clients who intend for others to consume their CRDs from third-party clients (or wrappers).

This is the use case I'm after. Create CRDs and operators using kubebuilder, but generate client libraries in languages other than go.

[DirectXMan12]

/help

[k8s-ci-robot]

@DirectXMan12:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[gclawes]

/remove-lifecycle rotten

[gclawes]

Is it possible to revisit this?

[vincepri]

We could add a new generator to controller-tools that given some paths to api folder, it generates OpenAPI spec files using the content that's today under openAPIV3Schema

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[estroz]

This feature request is specific to controller-gen and not necessarily something kubebuilder needs to know about until it is implemented there. I suggest this is closed here and re-opened in controller-tools.

/close

[k8s-ci-robot]

@estroz: Closing this issue.

In response to this:

This feature request is specific to controller-gen and not necessarily something kubebuilder needs to know about until it is implemented there. I suggest this is closed here and re-opened in controller-tools.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.