Generate types automatically

[mhristache]

Hi

Have you considered generating the types automatically from Kubernetes OpenAPI spec, for example using https://github.com/Arnavion/k8s-openapi-codegen?

//Max

[anguslees]

Yes, that was my plan - I just wanted to get a feel for the types "manually" before I worked on code generation.

Now that I have implemented a few API types by hand, I've learned:

• The openapi spec is not very comprehensive. "Optional" fields, for example are not called out as such, and require parsing the original golang code and structured-comments.
• Even the golang structs don't contain all the information necessary for a "good" translation into Rust. In particular, (C-like) enums are not called out as such in golang (example), and default values are buried in code and english comments.
• Otoh, manually implementing everything is boring and error-prone.

So, I'm in a quandary. I think what I should do is hack up something to help generate a first pass at the API types, and then apply some human effort to the results. Maintaining the result going forwards will also require human effort, unfortunately. I don't see that I have a choice however, unless I'm willing to accept significantly less descriptive types :(

Opinions/patches sought.

[rbtcollins]

Opinion: those defects upstream should be fixed upstream.

1. Fork upstream
2. Patch to get good codegen results with some enhanced codegen
3. Profit 3a. Submit the patches back upstream.

[anguslees]

Having thought about this more, I think we should declare bankruptcy on the openapi spec and work to re-describe the k8s API (really just the resource objects) in a new "better" IDL. I know that's radical, so I don't suggest it lightly.

We need to add more information above what's currently available in the golang types, and hence generated openapi spec (eg: enums, default values). We could augment the openapi spec, but openapi is quite clumsy and verbose to use as the primary declaration (designed mostly for documentation rather than codegen, already extended with non-standard fields in k8s so it's not like we can use standard openapi codegen tools anyway).

I think the right thing to do is to come up with a new language-neutral k8s-IDL, and back-generate the openapi (and other clients, like golang and Rust) from that. Ideally one day, we would also generate the official golang client - but importantly I don't think we should block by trying to "fix upstream" first because the priorities and incentives are not aligned.

I would be interested in any other non-go/rust language clients that have might have had similar thoughts.