Rubynetes: Using OpenAPI to validate Kubernetes configs | Hacker News Reader

Rubynetes: Using OpenAPI to validate Kubernetes configs

brightbox.com

40 pointsneilwilson9 comments

I am just today wrestling with the OpenAPI-generated libraries for Java and, summarising: I hate it.

I even went as far as trying to set up my own code generator using the OpenAPI generator toolkit. It is not my favourite code. Everything is deeply nested inheritance hierarchies with humptyjillion methods that do oddly specific stuff. I eventually gave up on it.

Now I am at the point where, to map the generated types to the same types described in the original OpenAPI YAML, I have about 50 goofy lines of string juggling and chasing data structures through 4 or 5 levels of nullable references.

I don't know how we wound up here but I wish we hadn't.

IME that's more of a problem between Java and the generator than it is OpenAPI. Expressing things feels clunky when generating Java code in general. Which, I stress, is not to say it's not a problem, and it super sucks when you hit it.

The languages I tend to consume OpenAPI in the most are TypeScript (great), Ruby (pretty good), and on-demand JavaScript (really flexible and comfortable) via openapi-js. I've had some luck with the Kotlin generator on the JVM, too.

As it happens, my main code is in Kotlin. I found myself thinking "maybe I could do a better generator" and then my fingers and toes began to tingle ominously.

You very well may. The generators are, right now, the worst part of the entire OpenAPI experience. But they're getting steadily better.

Interacting with generated code is never going to be as nice as hand-written code. It is a tradeoff to express semantics that exist in the interface definition language and the n- languages that the generator targets.

Go and "oneof" in protos is always fun: https://github.com/jrockway/ekglue/blob/master/pkg/glue/glue...

But it's better than saying "welp, that program is written in c++, so you have to write your tools that interface with it in c++ as well."

Actually I’ve been through this but since we use Scala and our HTTP client wasn’t accounted for in default generators I went straight to writing a plugin for the ehm code-generator toolkit.

Mostly same observations, but I actually made that plugin work. In retrospect writing complete generator from scratch would take far less time and effort.

I believe original authors have never written a compiler nor considered a code-generator to be a compiler (which it is). Hence the funky architectural style - whatever was the conceptual model behind it fits poorly to the problem at hand and likely was patched multiple times to cover niche corner cases.

Ultimately, you have to ask the API server because of things like admission webhooks:

https://kubernetes.io/docs/reference/access-authn-authz/exte...

The k8s API server might also have validation webhooks with stricter requirements than the OpenAPI validation included with the CRD.

And also because the API schema doesn't express state machine constraints.

For example, you can't modify some fields of a statefulset or a job after they've been created. The read-only state of certain fields depend on the status of the object.

Validating purely with OpenAPI also won't catch things like a volume mount referencing a secret that doesn't exist.

At the company I work for, I built some tools for deploying apps that wrap around kubectl, Helm, etc. To "lint" a Kubernetes manifest for deploy, the tool pipes the data through "kubectl apply --server-dry-run" first. (You can also use --dry-run for pure client-side validation.) Works pretty good.

Reply on news.ycombinator.com