Comment by ivan4th
5 days ago
Helm is an abomination, as the whole idea of using a text template engine to generate YAML is. And this vulnerability adds insult to injury ;)
Sorry, just can't really recover from trauma of counting spaces and messing up newlines, etc. when writing Helm templates. You know, Lisp "sucks" because "you need to count parenthesis" (you actually don't), yet Helm is a widely accepted technology where you need to count spaces for (n)indent ;)
I'm a dev that jumped to devops and one of my pet peeves will always be the lengths devops engineers go to avoid using a real programming language. Instead of interacting with all these APIs through python, ruby, lua, go, whatever they would rather build hodgepodge systems in bash, coreutils, curl (or wget. or both!) and jq (which is the worst). Or in the case of helm, just creating a half yaml/half Go SDK for generating YAML.
Even the helm infrastructure that I work in is completely wrapped in custom shell scripts that call all sorts of other commands to populate helm variables.
But yeah it's silly that helm templates require all sorts of {{ indent | 4 }} type incantations when the final YAML output is just sent through some kind of toJSON anyway.
You'll often find that if you write ops scripts in, say Python, it's largely calling external commands.
When that's the case, bash if often the better choice, especially if you know it well. It has an excellent REPL, is easy to trace and is already installed everywhere.
> You'll often find that if you write ops scripts in, say Python, it's largely calling external commands.
That's a totally fine trade off for actual sane array/list functionality, robust string manipulation etc. I'd rather form shell commands in a programming language than in bash. People seem to love it.
I do not think for a second though that the average person that "knows bash well" can read and comprehend a multi hundred line bash script written by someone else as fast or even correctly has a seasoned python dev reading python written by someone else.
> the lengths devops engineers go to avoid using a real programming language
OK, but, you know... those tools were created by literal devs. Not in yaml, in a "real language"! So apparently devs thought they needed that.
The argument should be towards all people - we love creating new abstractions and "simplify things", but we suck at honest evaluation of the impact of our creations.
Still: I absolutely hate Helm templating and think that the very existence of "helpers" (even in a default chart!) is an abomination.
> OK, but, you know... those tools were created by literal devs.
All `kubectl` does is create REST API calls to the control plane. So to be fair, what I'm grousing about can be accomplished just fine by a developer like me constructing API calls from python to update objects in k8s.
The problem is I work in devops where tooling written in proper languages with standard libraries that have things like useful arrays or robust string manipulation or ergonomic concurrency is a non-starter for some reason. The argument against that being mostly "I have to install the interpereter first".
1 reply →
Yeah, vi has supported % as "jump between matching parenthesis" since it's original release in the 1970s, and vim by default will do simple parenthesis matching and highlighting, I don't see why everyone is so scared of touching lisp for these reasons with modern editors (if your editor doesn't support either of the above... maybe it's not modern enough?)
This isn't a uniquely helm thing though, they mostly use modified go templating. Lots of other things do this with yaml as well.
… and I think I'd argue that the parent's argument against the tooling would apply equally as well to those "other things", too.
The alternative here is something that manipulates the data structure directly. E.g., it might permit me to say:
(This is in some pseudo-imperative language, vs. the parent's Lisp, but that distinction isn't particular relevant to the core of their argument, I think.)
And then at the end, the thing itself takes care of converting the resulting objects to YAML, thus preventing me from inadvertently turning what is meant to be a string into something like an accidental YAML-injection that results in terrible errors because I miscounted the number of spaces to indent something.
I wrote a small terraform wrapper around helm provider that basically does what you’re saying. official kubernetes + tf support is poor, but it’s been working well for me. I rarely if ever have to touch the yaml templates that I maintain.
however, this is usually true with working with helm in general if you are using charts other people maintain. That’s one of the strengths of helm. you just shove your values into the chart and it should work. Maintaining charts is not fun though which is why I wrote the wrapper for my purposes.
The funny thing is helm is as good or bad as what you make it. When folks complain about helm they are actually complaining about their own self created charts or poor selection of charts they install.
Something like kustomize was a better approach, where resources are templates semantically.
Though it's lacking in several ways, like good destroy functionality.
I like wrapping with kapp for this. However kustomize still skips hooks if you inflate a chart that uses them and there is value in discoverability of helm apps installed with clear versioning
I don’t think there is a lot of overlap between people who say lisp sucks because of the parens and people who are fine with using a template to generate yaml.