> ... maybe, Ansible should consider not using yaml for absolutely everything. Maybe. But what problems with Ansible are you trying to solve by using addition

> ... maybe, Ansible should consider not using yaml for absolutely everything. Maybe. But what problems with Ansible are you trying to solve by using additional, and perhaps domain specific, languages? I haven't used Ansible, but I do use SaltStack, which also relies on YAML, and also uses Jinja, hence my interest here. SaltStack, and I'm assuming Ansible can do this too, will happily use whatever you want, even raw python, as state (configuration) files, so long as they can generate yaml. This is not as inelegant as it sounds :) -- it means configuration length & complexity can be represented by (or hidden behind) short, palatable algorithms. As soon as the suggestion is made to introduce yet another DSL to a system, you end up with holy wars about which one, and then a total mess trying to integrate and support both. Anyway, if you don't want to use YAML / Jinja, then eschew SaltStack, Ansible etc in favour of Chef, Puppet, SCCM, etc.