Hacker News Reader

Comment by oftenwrong | Hacker News Reader

    {{ toYaml .Values.labels | indent 4 }}

    {{- include "grafana.labels" . | nindent 4 }}

Building data structures by piercing together strings like this is a bit questionable.

View on HN

This is neither yaml nor Jinja. It's a Helm chart, which uses Go templating to generate yaml programmatically. The point of this is all of the actual config is in Values.yaml, which generates the .Values object referenced here, and you use those values to generate all of your deployment definition, making it easy to apply environment-specific overrides by switching out a single file and leaving everything else alone.

So yeah, if Helm is complicated, sure, don't blame yaml for that. Similarly, I'm not sure all of these declarative CI examples are all valid yaml either and not fed through front-end preprocessor first. They're essentially feature-identical with Jenkins declarative pipeline minus the ability to run arbitrary Groovy code in your build scripts, though of course you can get this exact behavior if you want by feeding a HEREDOC to a sh step that invokes the Groovy interpreter.

In any case, the author calling CI workflow definitions "config" is a little misleading. They're necessarily more complicated than a properties file and need to allow you to invoke external tools. Newer language ecosystems like Go and Rust are trying to solve this by putting dependency management, compiler, packager, and testing all into one tool provided with the language installation, but even there a lot of CI/CD needs to do a lot more than that, like deploy infrastructure, build container or VM images, etc.

Author Here. Thanks for reading. I am not trying to be misleading. I'm trying to point out that although each step along the way of adding things to config seems to make sense, you arrive in a bad place.

People start with some YAML, and everything is fine. Then a simple condition is added, so ok, we are treating code as data, LISP style but in YAML. Then the logic and branching grows, and we introduce templates and so on.

You start with config, then the config ends up with its own config, and eventually, you are using Skaffold to configure Helm, which generates your YAML. That can't be the right solution, can it?

https://skaffold.dev/docs/pipeline-stages/deployers/helm/

The point is that CI workflow orchestration and clustered application deployment definitions are not config, at least not in the same way as “here is some hierarchy of definitions that change the behavior of an application.” These are attempts to create declarative DSLs that script workflow steps. In the Helm case specifically, the templating engine produces yaml because Kubernetes uses yaml for its manifests, and Kubernetes uses yaml for manifests because it provides a one to one mapping to the actual data structures used by the cluster manager. It’s way beyond config. You’re defining the entire state of a clustered application, including the infrastructure. Only the Values.yaml is config and I don’t see how that alone is all that complicated.

I don't blame YAML for Helm's approach. I'm also not anti-templating, but templating the DSL as a string, and manually setting the indentation level strikes me as a particularly hacky approach. Compare with something like https://jsonnet.org/ (no endorsement), which let's you do the same kind of substitution, but directly in the structure of the data.

That looks like Jinja that outputs YAML, doesn't seem fair to blame YAML (which I think the author sort of does) just because someone wanted to bolt an include statement onto it.

Because YAML is an abomination that uses spaces for logic, there isn't any other way if you need YAML at the end ( like you do with Kubernetes).

Reply on news.ycombinator.com