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.

  • walter_wiggles@lemmy.nz
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    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.

    • gsfraley@lemmy.worldOP
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      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.

      • walter_wiggles@lemmy.nz
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        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.