Conversation
The OpenAPI v2 schema that the modelshema tool outputs lacks paths, and is formatted specifically to be consumed by other internal tools. Rather than mess with it, create a new tool that outputs schemata specifically designed to be consumed by third parties. This new tool supports generating a schema from any CRD definition, and will output a schema on the same level as the schema in the main Kubernetes project. Also add a hack script to generate schema files for both channels.
While the OpenAPI spec was technically correct, it defined most fields on objects as plain objects. This is because they are loaded from the CRD definition, which lacks typed object information. This makes generating clients from this spec not very useful. However, we have the actual full object spec in exported Go form. If we load that, we can substitute those definitions in, and now we have full object models. There is a bit of weirdness with the names of things not lining up, but a quick rewrite fixes that.
The Golang genereated API defs seem to lack these keys, but only at the top level. Thankfully the CRDs have them, so we can take them from there.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Rycieos The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Welcome @Rycieos! |
|
Hi @Rycieos. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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-sigs/prow repository. |
What type of PR is this?
/kind feature
What this PR does / why we need it:
As mentioned in the linked issue:
The OpenAPI v2 schema that the modelshema tool outputs lacks paths, and is formatted specifically to be consumed by other internal tools. Rather than mess with it, create a new tool that outputs schemata specifically designed to be consumed by third parties.
This new tool supports generating a schema from any CRD definition, and will output a schema on the same level as the schema in the main Kubernetes project.
Also add a hack script and
maketarget to generate schema files for both channels.I see three options for how this could fit in this project's release workflow:
/api/openapi-spec, like in the main Kubernetes project.Which issue(s) this PR fixes:
Fixes #4581
Does this PR introduce a user-facing change?:
Example outputs:
To prove functionality, I ran this tool to generate API specs for versions 1.1.0 through 1.5.0. I did this with the following shell snippet:
standard-swagger-v1.1.0.json
experimental-swagger-v1.1.0.json
standard-swagger-v1.1.1.json
experimental-swagger-v1.1.1.json
standard-swagger-v1.2.0.json
experimental-swagger-v1.2.0.json
standard-swagger-v1.2.1.json
experimental-swagger-v1.2.1.json
standard-swagger-v1.3.0.json
experimental-swagger-v1.3.0.json
standard-swagger-v1.4.0.json
experimental-swagger-v1.4.0.json
standard-swagger-v1.4.1.json
experimental-swagger-v1.4.1.json
standard-swagger-v1.5.0.json
experimental-swagger-v1.5.0.json
EDIT: added v1.5.1 specs (identical to v1.5.0).
standard-swagger-v1.5.1.json
experimental-swagger-v1.5.1.json