Allow other OpenAPI specs, e.g. Openshift

[arnavion]

Allow other OpenAPI specs, e.g. Openshift

[Arnavion]

Yes, please do that.

[Arnavion]

From a cursory glance at the spec, at least these things will need to change / become flexible:

• More SupportedVersions for OpenShift versions

• Some definitions are under a new com.github.openshift.api namespace. This would need to be collapsed to ::openshift like io.k8s is collapsed to :: right now.

• The x-kubernetes-group-version-kind annotations on the com.github.openshift.api definitions are strange. There are two of them for each definition with different group names. It might trip up the code generator.

• Other things?

That said, I'm not sure I want to have OpenShift bindings in the k8s-openapi crate, or even in this git repo, though I'm open to being convinced otherwise. The main reason is that I wouldn't test the OpenShift bindings in any way, so I think it'd be better if they were maintained by someone who cares about them.

It might work to make the code generator flexible enough to support it, but the bindings can live in a separate OpenShift-specific bindings repo (not maintained by me) that references the code generator from this repo through a git submodule reference or something.

If you're up to it, could you make a PR / fork with all the changes needed to generate valid bindings for OpenShift specs? Once I have a list of all the things that need to change in the code generator, I can make a more informed decision.

[ibotty]

I will have a look at it in the following days. I would definitely try to maintain them and set up some tests so you feel confident having them in the repo. Due to the non-modularity in k8s-openapi-users I would prefer the bindings to be in k8s-openapi for now, but let's talk when I have a proof of concept.

[Arnavion]

It might work to make the code generator flexible enough to support it, but the bindings can live in a separate OpenShift-specific bindings repo (not maintained by me) that references the code generator from this repo through a git submodule reference or something.

v0.5.0 modularized most of the codegen into a library crate since it needs to be shared by the original code generator as well as the new proc macro crate. This should make it easier for out-of-tree bindings crates.

[ctron]

I started to work on this at https://github.com/ctron/openshift-openapi … I had to make a few tweaks to the k8s-openapi generator, see: https://github.com/ctron/k8s-openapi/tree/feature/openshift_api_1

But I was hoping to bring back the requires features of the code generator to k8s-openapi.

[Arnavion]

I'll look at it this weekend.

[ctron]

@Arnavion I can open a draft PR if you like?! I simply didn't want to throw that at you, because I am not sure that I would merge that in the current state 😁 But I guess it might a good starting point for discussing.