dealing with CRDs?

[clux]

The API for CRDs is generated by kube as soon as the CRD is posted. Thus these structs are not normally available in the openapi bindings or something else (the crd might not even have a schema in older versions of kube). This is usually not a problem, because if you're using rust, you might have a more precise struct for this anyway, but it would be nice to have an API wrapper for this call somehow maybe?

The go toolchain does some awkward codegeneration that they force people to do more-or-less manually, but that shouldn't be necessary when you have serde and rust on your side. Still, not sure what's the best way to tackle this.

Currently, am just calling the api the easy way:
https://github.com/Babylonpartners/shipcat/blob/8e1fd9c1e0bfef1a9f642f9d7d64b1b938f00ae2/raftcat/src/kube.rs#L13-L19
(and thus avoiding the openapi bindings entirely because that's all i need atm)
but wondered if you/someone had thoughts on this.

[ynqa]

@clux Thanks also.

Firstly I tried to use generated codes by swagger-codegen/openapi-generator and not to edit them as possible. Because it's difficult to trace and maintain k8s APIs each version.

However, there are a lot of bugs on swagger codes. Therefore, I've adapted to use 3rdparty generators for requests (after all, this maintains swagger codes with sed-like operations).

• workspace: https://github.com/ynqa/kubernetes-rust/tree/gen
• modifying here: https://github.com/ynqa/gen/blob/rust/openapi/rust.sh#L54-L70

Since it has ended up such results, I'm considering whether to manage APIs (including CRD you pointed out) also for kubernetes or not.

[clux]

Ah, and you've switched to using hyper directly. I only saw that just now :<

[ynqa]

@clux Yes, but it's also not so good for tackling #6 issue. I'm considering to define APIs on my own codes.

[clux]

I've been trying to tackle this directly.

Have written an implementation of a reflector: https://github.com/clux/kubernetes-rust/blob/master/src/api/reflector.rs - to mimic what people do with client-go.

This allows us to write kubernetes operators by doing stuff like: https://github.com/clux/operator-rs

Tried to go down the k8s-openapi route, but the calls for instances of CRDs just weren't there. And even if they were there, the hardest part is writing some stuff that synchronises it.

How do you feel about maybe having crate for all the stuff for the kube config, and one config for extras?

[ynqa]

@clux I'm looking over this example:
https://github.com/Arnavion/k8s-openapi/blob/master/k8s-openapi-tests/src/custom_resource_definition.rs