Closed MOZGIII closed 3 years ago
It's an aggregated server so it isn't part of the default swagger.json
, and the https://github.com/kubernetes/metrics repo doesn't have a swagger.json
either.
If we assume the cluster's openapi endpoint will start exposing it once you register the aggregated server, then https://github.com/Arnavion/k8s-openapi/issues/38 will probably work for it. But doing it as part of k8s-openapi
's build process is more challenging, because it means every build has to deploy a test cluster and source the swagger.json
from there, instead of just fetching upstream's files https://github.com/Arnavion/k8s-openapi/blob/ce394e940ccc01a086b30546b6dbce143d46c71d/k8s-openapi-codegen/src/supported_version.rs#L43-L51
I didn't try, but what if we could generate the spec via https://github.com/kubernetes/kube-openapi/tree/master/cmd/openapi-gen?
Also, https://github.com/kubernetes-sigs/metrics-server might be easier to get the spec from directly.
I didn't try, but what if we could generate the spec via https://github.com/kubernetes/kube-openapi/tree/master/cmd/openapi-gen?
That tool being shit for Rust (and shit in general) is why this repository exists in the first place. See the README.md
Also, https://github.com/kubernetes-sigs/metrics-server might be easier to get the spec from directly.
I don't see a swagger.json
there either.
Can't we use it to generate the OpenAPI Spec (or swagger.json
), and from that point on use the k8s-openapi-codegen
?
My bad, openapi-gen
does the reverse of what I thought it did.
I'm not really enthusiastic about adding a golang dependency on the crate build either.
Thinking about this some more, I'm not sure how this would work at all. The fact that it's an aggregated server means it releases independent of the main API server. There's no one-to-one mapping of the API server's API with the Metrics server's API, so combining its generated code into the main k8s-openapi
crate makes no sense.
This should be done in an independent crate, which can use k8s-openapi-codegen-common
crate for codegen if it needs to, and how it procures the openapi spec is that crate's problem.
Right, that was my thinking as well, on both of your points. So, this brings me to the next question - is there a way to reuse even more code - and use shared generated types - if one would want to build a dedicated crate to keep the Metrics API at.
I presume, ideally, this project would want to support everything that https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io keeps around. Ideally. However, in practice, the support for anything outside of the "main" API it technically way more difficult due to the lack of generated API specs, untied/unsynced updates and etc. So, it's probably not worth the effort, at least in the current situation.
I wonder though: what are the practicals ways do we have now if we want to work with those APIs? It seems like a simple tool to generate the OpenAPI Spec files for those "non-main" APIs would technically enable the ability for people to build and support crates to work with those APIs. This problem can only be solved properly by the Kubernetes project itself, but workarounds like an ad-hoc OpenAPI spec generator may serve us until that happens...
You can take a look at what https://github.com/ctron/openshift-openapi does.
How difficult would it be to add Metrics API generation to this project?