Skip to content

OpenAPI v2 spec generation#4686

Open
Rycieos wants to merge 4 commits intokubernetes-sigs:mainfrom
Rycieos:feature/openapi-generation
Open

OpenAPI v2 spec generation#4686
Rycieos wants to merge 4 commits intokubernetes-sigs:mainfrom
Rycieos:feature/openapi-generation

Conversation

@Rycieos
Copy link

@Rycieos Rycieos commented Mar 13, 2026

What type of PR is this?

/kind feature

What this PR does / why we need it:
As mentioned in the linked issue:

Similar to the main Kubernetes project, I want an OpenAPI v2 spec in JSON that can be consumed by clients.

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 make target to generate schema files for both channels.

I see three options for how this could fit in this project's release workflow:

  1. Make running this tool part of the release process, and add these spec files to the GitHub release. I added the documentation for this option in this PR (for now).
  2. Make running this tool part of the codegen steps, and end up with the files in the some directory like /api/openapi-spec, like in the main Kubernetes project.
  3. Don't include this tool anywhere, and leave it up to users to figure it out.

Which issue(s) this PR fixes:

Fixes #4581

Does this PR introduce a user-facing change?:

- Releases now contain OpenAPIv2 schema definitions.

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:

directories=(config/crd/ pkg/generated/openapi/);
git_reset() { # ref
  git reset -- "${directories[@]}"
  rm -rf "${directories[@]}" 
  git checkout "$1" -- "${directories[@]}"
}
for tag in v1.1.0 v1.1.1 v1.2.0 v1.2.1 v1.3.0 v1.4.0 v1.4.1 v1.5.0 v1.5.1; do
  git_reset "$tag"
  ./hack/build-openapi-json.sh --version "$tag"
  mv release/standard-swagger.json "release/standard-swagger-${tag}.json"
  mv release/experimental-swagger.json "release/experimental-swagger-${tag}.json"
done
git_reset HEAD

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

Rycieos added 4 commits March 13, 2026 16:57
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.
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/feature Categorizes issue or PR as related to a new feature. labels Mar 13, 2026
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Mar 13, 2026

CLA Signed
The committers listed above are authorized under a signed CLA.

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Rycieos
Once this PR has been reviewed and has the lgtm label, please assign rikatz for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot
Copy link
Contributor

Welcome @Rycieos!

It looks like this is your first PR to kubernetes-sigs/gateway-api 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/gateway-api has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

@k8s-ci-robot k8s-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Mar 13, 2026
@k8s-ci-robot
Copy link
Contributor

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. and removed cncf-cla: no Indicates the PR's author has not signed the CNCF CLA. labels Mar 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/feature Categorizes issue or PR as related to a new feature. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add OpenAPI v2 JSON spec as generated file

2 participants