[Question] Difference with kubernetes-client/gen

[ngortheone]

Hi @Arnavion
As I was exploring available options for kubernetes clients for rust I found out that @ynqa in his ynqa/kubernetes-rust#10 is moving away from your library and tries to use https://github.com/kubernetes-client/gen

On the surface it seems like reinvention of the wheel, so I decided find out if there is substantial difference between kubernetes-client/gen and your approach and why kubernetes-client/gen might not want to accept a client that was not generated with their generator.

I believe that you did some kind of research before writing your own generator, so there must reason for that. Could you please share your perspective?

[Arnavion]

Most of the differences amount to this crate doing things specific to Kubernetes's OpenAPI spec that a generic swagger generator does not.

Almost everything in https://github.com/Arnavion/k8s-openapi-codegen/blob/15777b259ac16cc4287da3ede50f62d3c4508be9/src/fixups.rs is what an automatic swagger-generated client gets wrong. You don't have to read the code, just read the comments.

• Some of these are fixed in new versions of the OpenAPI spec in upstream so they only apply to older versions, which is why you won't find the mistake in that PR's generated code. But this repo generates specs for older versions too so it needs them. I'm not sure what that crate's policy will be to generate clients for older versions of Kubernetes. Edit: See here for the breakdown of fixes required for each version.

• Kubernetes uses x-kubernetes-* annotations to annotate the APIs in the spec and this crate uses them to make the API as inherent methods of the corresponding struct, like Pod::list_core_v1_namespaced_pod. The swagger-generated specs don't do this, so they put all API in giant top-level traits.

• The OpenAPI spec has a lot of typedefs under the io.k8s.kubernetes.pkg namespace, which was where the types originally lived in v1.7 and are now just kept for backwards-compatibility. The code generated by that PR handles them badly. This crate just ignores them.

• The very first diff at https://github.com/ynqa/kubernetes-rust/pull/10/files#diff-04c6e90faac2675aa89e2176d2eec7d8R26 suggests to me that that generated client isn't taking optional parameters into account properly, given that it requires the caller to pass in "" and 1 instead of None. Also note that the next release of this crate will remove the need to pass in so many explicit None for optional parameters, since these have now been moved to a separate Default-able struct.

• Most importantly, the APIs generated in that PR are all synchronous, since they're all functions that take parameters and return Result<Response>, and internally use reqwest::Client. AFAIK the swagger generator is configurable in this regard, since I remember one of the other swagger-generated Kubernetes clients on crates.io is asynchronous (uses hyper::Client internally).

  But neither of these options is good in my eyes since I would like the user to use whatever they want, which is why the API generated by this crate uses the sans-io approach which was popularized by Python.

[ngortheone]

Thanks for a very detailed answer!

Does it mean that as official kubernetes-client/gen will get better at handling those issues this repo/crate will become obsolete? (Is there a chance that official gen will become better?)

Separately
Would you be interested in a PR with enhancements to readme/docs with this information, and information that I can find in other issues ?( e.g. intended usage : #20 #24 #17 )

[Arnavion]

Does it mean that as official kubernetes-client/gen will get better at handling those issues this repo/crate will become obsolete?

That depends on the effort that that crate puts. You would have to ask its maintainers.

Would you be interested in a PR with enhancements to readme/docs with this information, and information that I can find in other issues ?

Yeah, sure.

Also, thanks for reminding me about #17. I've updated my comment there.

[ngortheone]

Information collected in
#27