[sciyoshi]

Agreed on avoiding yaml templating at all costs, but I've also found that you don't normally need a full programming language for these types of config files - if you do find yourself reaching for those tools you might be better served by something like Dhall https://github.com/dhall-lang/dhall-lang (which has its own K8s bindings as well)

[gilbetron]

Huh. When I first looked at it my reaction was, "this is stupid!", which I've figured out over the years is my inner-ape reacting to the alien, and is an indication that something is the opposite of stupid. So I read more about it and it seems really cool - possibly too much for most people, but that makes it even more interesting! Thanks for pointing it out!

[mkobit]

YAML templating is something I've come to truly hate. It seems that tools and services want the configuration to be "simple" by using a format that is fairly easy for humans to parse while not trying to force a language specific tool onto the users. However, when they move into the inevitable phase of wanting to be more configurable, they can move into confusing, unintuitive, and surprising territory. It also doesn't help that everybody keeps inventing their own way to do it. A few examples of YAML bastardization that give me headaches trying to understand:

* saltstack Jinja templating [1]

* GitLab CI `include` directive for including and merging external CI files together [2]

A few tools that I have seen take a decently pragmatic approach:

* Kubernetes resources that use ConfigMap and `envFrom` that declaratively say where to resolve a value from [3]

* Circle CI commands which offer some reusability with its "commands" and "executors" type features [4]. To me, Circle CI has both good and bad aspects with some templating and some clever patterns

On the other side of things, there is essentially fully programmable type configurations like Jenkins Pipeline Groovy `Jenkinsfile`, which can be a nightmare, too.

I think it is tough to find a sweet spot between making it configurable and expressive for users while retaining a low barrier of entry and not turning the configuration into a complete program itself. Tools like Terraform are trying to find that sweet spot as they slowly introduce more programmatic ways of configuration while still being declarative, like the fairly recent introduction of if statements and soon (I think) to be released for loops. As soon as users of a tool and service have more complex use cases, there needs to be some way to solve that. The most common way (it seems) is taking the easy and familiar of introducing templating.

[1]: https://docs.saltstack.com/en/latest/topics/jinja/index.html

[2]: https://docs.gitlab.com/ee/ci/yaml/#include

[3]: https://kubernetes.io/docs/reference/generated/kubernetes-ap...

[4]: https://circleci.com/docs/2.0/configuration-reference/#comma...

[vorg]

> there is essentially fully programmable type configurations like Jenkins Pipeline Groovy `Jenkinsfile`, which can be a nightmare, too. I think it is tough to find a sweet spot between making it configurable and expressive for users while retaining a low barrier of entry and not turning the configuration into a complete program itself.

Nowadays, Jenkins pipelines can be configured in either the Jenkins-provided "Declarative Syntax" [1] or the Apache Groovy-based "Scripted Syntax", with the Declarative Syntax used as the default for examples on the Jenkins website. I guess they've found the best way to not have users turn the configuration into a complete program is to provide declarative syntax only in the default option. It's good to see Kustomize is built with this in mind, too.

[1]: https://jenkins.io/doc/book/pipeline/syntax/