Ansible configuration exists in YAML files which look static but are deceptively dynamic: values in these files get parsed as static values, Python expressions, or Jinja2 templates that may themselves contain Jinja2 filters and Python snippets. This mish-mash of conceptual models leads to awkward syntax that requires careful quoting and a constant mental effort to separate each of the three layers (static YAML, Jinja2 interpolation/filtering, and Python evaluation).
Some example sources of discomfort:
- The context-dependent need to quote Jinja2 syntax interpolation ({{ ... }}) in some places but not others, due to conflict with YAML syntax rules.
- Undifferentiated mixing of Python evaluation (eg. list concatenation with +) and Jinja2 filtering/transformtion (eg. `| zip` and `| list`) in a single value.
- Awkward encoding of imperative programming patterns using YAML keys (eg. `loop` and `loop_control` to describe a loop; `when` to describe a conditional).
- Context-specific embedding of Python expressions (eg. raw Python code being passed as a string in the `when` property, but elsewhere being interpolated in Jinja2 interpolation).
- Implicit/magical variable naming conventions (eg. use of loop implies the existence of an `item` variable).
- No obvious scoping rules eg. variables magically available with no obvious source (they are defined in another file, or defined in a prior task).
That's from an example I wrote up over on my dotfiles repo:
https://github.com/wincent/wincent/tree/master/fig#on-ansibl... - I used Ansible happily enough for years there, but concluded that at least on a little toy project like that it was more fun/pleasant/simpler to just embody the imperative, procedural work in an actual programming language. I still use Ansible in other places, to manage remote hosts, but I can't shake off the discomfort I feel about how it uses YAML.
The loop variable can be specified, and if anyone is writing a playbook for other people to read / use, then they should absolutely do this. It is a problem that writing things in the most clear and reusable way isn't the most obvious way. Fairly basic things like copying directories or looping over files have really good solutions, but it takes time for someone to come around to those patterns. So this leaves around a lot of ugly implementations. Some improved hand-holding layer could be productive.
A well-designed abstraction makes optimal usage fall out naturally. It would be very difficult to make the claim that optimal usage "falls out naturally" when one uses Ansible, and yet another layer of abstraction on top would more likely than not just increase the already staggering complexity in the system.
I understand you're making a lot of good points; However, Jinja templating happens "before" it becomes YAML.
It's not "injected" into the YAML.m
I get people have criticisms; But it's not like these things are very difficult to overcome. Outside of creating a DSL, what could actually be different?
It sounds like your complaints are more to do with Jinja + YAML and Ansible was unfortunately a victim of some of those issues?
While a lot of negatives are pointed out about the marriage between the two, there are still at least some positives I believe.
Disclaimer: I have nothing to do with the tool outside of using it.
when we compared salt and ansible a few years ago to decide which one to choose, this issue of yaml scripts was what let us to decide against ansible. we looked at examples how to set up user accounts, and the example ansible offered at that time was just atrocious. it is possible that ansible now has better ways to configure users, but at the time that was what a red flag for us. (we also checket puppet, but our junior admin tasked to test it couldn't even get it to work after a week of trying, so that failed too)
Some example sources of discomfort:
- The context-dependent need to quote Jinja2 syntax interpolation ({{ ... }}) in some places but not others, due to conflict with YAML syntax rules.
- Undifferentiated mixing of Python evaluation (eg. list concatenation with +) and Jinja2 filtering/transformtion (eg. `| zip` and `| list`) in a single value.
- Awkward encoding of imperative programming patterns using YAML keys (eg. `loop` and `loop_control` to describe a loop; `when` to describe a conditional).
- Context-specific embedding of Python expressions (eg. raw Python code being passed as a string in the `when` property, but elsewhere being interpolated in Jinja2 interpolation).
- Implicit/magical variable naming conventions (eg. use of loop implies the existence of an `item` variable).
- No obvious scoping rules eg. variables magically available with no obvious source (they are defined in another file, or defined in a prior task).
That's from an example I wrote up over on my dotfiles repo: https://github.com/wincent/wincent/tree/master/fig#on-ansibl... - I used Ansible happily enough for years there, but concluded that at least on a little toy project like that it was more fun/pleasant/simpler to just embody the imperative, procedural work in an actual programming language. I still use Ansible in other places, to manage remote hosts, but I can't shake off the discomfort I feel about how it uses YAML.