Mistletoe Package Manager (WIP) -- Run WASM, Get Kubernetes YAML

gsfraley@lemmy.world to Programming@programming.dev – 22 points – GitHub - gsfraley/mistletoe: A completely programmable Kubernetes package runner
github.com

Hey all! I'm looking for some input on an idea I've been kicking around for a while and just started hacking on the past few days. I call it "Mistletoe", and it's yet another Kubernetes package manager, like Helm. I'm writing it due to some frustrations I've had with Helm in the past not supporting more complex cases.

I'm still in the early stages, so only the most trivial parts work, which is why I wanted feedback before I really put the gas on. The cliff's notes are that it's a Kubernetes package manager where the packages are WebAssembly modules that take input YAML strings and output Kubernetes resource YAML strings. It turns out that writing packages for it is pretty braindead simple, so I have high hopes, but please feel free to give me a reality check if I'm spouting nonsense.

7

I don't like the idea of replacing one well known YAML schema (k8s as much as I hate it is well known), with another YAML schema that is not well known. I think I'd rather use something to get away from YAML altogether, rather than just trade one for another. The reason helm and kustomize work well is that your existing k8s resource knowledge transfers, it sounds like it wouldn't with this thing.

Oh, it's all still Kubernetes YAML. The difference is in how it's represented. Helm Charts are packaged Golang templates of Kubernetes YAML, and as such have a whole lot of limitation since the only logic you can put into them is Golang template logic.

This is still Kubernetes YAML, but instead you write any program you want to return the YAML, as long as it fits in the sandbox, so it's pretty open-ended. For example, as a stretch goal, I might add an engine to it that could recompile Helm Charts into Mistletoe Modules.

I have no idea what any of your jibberjabber means but it sound suspiciously like an excuse to try to get someone to kiss you under the forced premise of a holiday tradition.

I think it would be helpful if you outlined where helm is falling short for you.

Personal opinion: I think packaging k8s manifests in OCI image format is probably the future. Helm, Kustomize, etc may still be useful in generating the yaml, but the "package management" part will be OCI image registries.

So Helm never fell short for me as an end user. As far as that goes, it's near-perfect.

Where it does fall short is as a package writer. A package in Helm is just Kubernetes YAML that's templated in Golang templates. As such, it gets very hard to any logic beyond the most basic, and projects that get larger get very unwieldy.

Hmm, what's your idea for the OCI image format, e.g., how would it work? That might be worth looking into, too.

OCI allows you to package arbitrary content in a docker image. In this case it would be a collection of k8s yaml files. Two main benefits of this approach are:

  • Your gitops tool only needs image registry access, not git access
  • The OCI image contains the final yaml. Your CI pipeline is responsible for generating the image.

Flux already supports this and I other tools to follow.