-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate openapi spec for CRD objects #1231
Comments
That's what controller-tools already generates OpenAPI data for CRDs as part of generating the CRD validation schema. Is that not sufficient? |
I haven't been able to find any documentation on that, could you point me in the right direction? |
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? |
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.
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). |
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.
We would like to consume it at compile-time and also to produce CRD documentation, so sadly this isn't an option. |
This is the use case I'm after. Create CRDs and operators using kubebuilder, but generate client libraries in languages other than go. |
/help |
@DirectXMan12: Please ensure the request meets the requirements listed here. If this request no longer meets these requirements, the label can be removed In response to this:
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. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
Is it possible to revisit this? |
We could add a new generator to |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This feature request is specific to /close |
@estroz: Closing this issue. In response to this:
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. |
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
The text was updated successfully, but these errors were encountered: