search

Arnavion / k8s-openapi

Rust definitions of the resource types in the Kubernetes client API
Apache License 2.0
384 stars 41 forks source link

Allow other OpenAPI specs, e.g. Openshift #24

Closed ibotty closed 4 years ago

ibotty commented 5 years ago

My use case is only OpenShift, but there might be other specs.

Does it make sense to "just" include OpenShift's OpenAPI behind feature flags, or should there be a generic mechanism to support supplemental specs?

Arnavion commented 5 years ago

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

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

I'll look at it this weekend.

ctron commented 4 years ago

@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 :grin: But I guess it might a good starting point for discussing.

Arnavion commented 4 years ago

Yes, please do that.