search

Arnavion / k8s-openapi

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

Metrics API #76

Closed MOZGIII closed 3 years ago

MOZGIII commented 3 years ago

How difficult would it be to add Metrics API generation to this project?

Arnavion commented 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

MOZGIII commented 3 years ago

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.

Arnavion commented 3 years ago

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.

MOZGIII commented 3 years ago

Can't we use it to generate the OpenAPI Spec (or swagger.json), and from that point on use the k8s-openapi-codegen?

Arnavion commented 3 years ago

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.

MOZGIII commented 3 years ago

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...

Arnavion commented 3 years ago

You can take a look at what https://github.com/ctron/openshift-openapi does.