Hacker News Reader

Comment by cheshire_cat | Hacker News Reader

Why do you want to stop using helm charts? Genuine question, as I'm new to Kubernetes and helm.

Write a few Helm charts and you'll understand why people want to stop using it. `nindent` will become a curse word in your vocabulary. It's a fine tool at the user level, but the DX is an atrocity.

I mean, I have written a few (like 5-10?) and I don't understand either. I find that Helm is quite a nice tool which does its job very well.

What are you planning on moving to ?

Probably kustomize, as my needs are simple. If I care to get fancy, I’m pondering giving Yoke a try.

What's wrong with `kubectl apply -f xxx.yaml`?

We use kustomize because we have four environments that run basically the same stuff (dev with k3s, test, and two cloud regions). If we didn’t use kustomize, we’d be forced to reinvent it to avoid duplicating so much yaml.

I used kustomize to build an ArgoCD install at a previous company, and I was impressed at how powerful it was. Our setup was pretty involved, and kustomize was able to handle all the per-environment differences easily, and the code was easy to work with.

I'm using either opentofu(terraform) or plain yaml. I'm not a huge fan of HCL but at least it is structured and easily manipulated without worrying about whitespace.

easily manipulated? How?

Golang string templating in a whitespace sensitive config language suuuuucks.

I might use Helm charts for initial deploys of operators, but that's about it.

Kustomize is, IMO, a better approach if you need to dynamically modify the YAML of your resources and tools like ArgoCD support it.

Consuming one that is well written isn't too much pain, IME. But writing or modifying one can be really annoying. Aiui the values.yaml has no type schema, just vibes. The whole thing is powered off using text templating with yaml (a whitespace sensitive language), which is error prone and often hard to read. That's basically the main issues in a nutshell, it may not sound like much, but helm doesn't exactly do a whole lot and it does that limited set of stuff poorly.

I share your dislike of Helm, but FYI there are schemas for values, see for example https://github.com/bitnami/charts/blob/main/bitnami/postgres... and docs https://helm.sh/docs/topics/charts/#schema-files

Ah, I must have met some lazy charts then. Thanks for the correction. Still, it seems like that schema would end up a little inconvenient to integrate into your editor for writing the templates...

Oh, yeah, but who can blame them because writing JSON Schema files by hand is some onoz

Ironically (in the context of this submission) Bitnami has a "--schema" option to their README generator, which is why so many of their charts ship with .schema.json files: https://github.com/bitnami/readme-generator-for-helm/tree/2....

There are likely other "give me a schema for this example JSON/YAML file" but almost certainly wouldn't come with the nice {"description":""} blocks, nor the {"required":false} that an annotated .yaml can offer

While digging up that link, I also spotted the tag line in their GitHub org which is hilarious https://github.com/bitnami#:~:text=trusted%20by%20ops

> a little inconvenient to integrate into your editor for writing the templates...

Another way that JetBrains tooling shines, because it automatically turns on JSON Schema support for the chart when it has one, no extra # schema=file://... dumbness required

That is when you are writing the values when using the chart though, right? Yeah that's not too hard.

I was talking about the go templates that make up the actual chart. Ensuring they only use string values for annotations for example seems like a hard problem to solve. Even just showing the type and description from the schema seems nontrivial.

I don't exactly follow which part you're talking about, but yes JetBrains propagates the type and description from the JSON Schema into the golang templates inside the manifest files, same as it does with any type completion. They are reflected as their JSON Schema types, not golang's types, which I could imagine is potentially confusing to someone used to golang's view of the world but is for sure considerably better than "hurr, the type is whatever you say it is" which will be the case for values.yaml files without an accompanying .schema.json file

---

As for the "only string values for annotations," I think you mean patternProperties:

  {
    "$schema": "http://json-schema.org/draft-07/schema",
    "type": "object",
    "properties": {
      "annotations": {
        "type": "object",
        "description": "this is the description of the annotations key itself",
        "additionalProperties": false,
        "patternProperties": {
          "^[a-z][a-z0-9./]+$": {
            "type": "string",
            "description": "holds the value of the annotation"
          }
        }
      }
    }
  }

and if I put the following, then the 123 gets flagged as a schema violation

  annotations:
    alpha: 123

as does

  annotations:
    _: xxx
    0xcafebabe: denied

---

If you mean schema checking on the output, that is checked by the OpenAPI built into Kubernetes itself, so yes, doing something silly in golang templates will not, by itself, check the result - that's one of the major limitations of Helm's moronic choice of using a text templating language for a structured file format

Oh, OK. I didn't realize it made them visible in the golang templates.

I will leave it to others: https://noyaml.com

Reply on news.ycombinator.com