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.
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.
Don't @ me with BS about putting logic in templates - I know what I'm doing.
If they're going to do that, the configuration files should just use a actual programming language. Just make them actual python files (or ruby files, or whatever).
From the famous quote:
> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
The problem here isn't that they're using lisp (or python, or yaml, or whatever), it's that they're re-implementing a very mature language with lots of supporting infrastruture poorly with lots of bugs and corner cases, rather then just using the relevant (open source) programming language itself.
I don't recall how ansible extends yaml, but Microsoft does something that sounds similar with their JSON-based ARM templates (which are for deploying cloud resources), adding functions for loops, parameters and variables. The result is predictably horrible. There are however at least APIs available for C# and others, so it's not the only automation option.
You use yaml to write code to some hidden programming language that doesn’t have any kind of formalized syntax.
Want to add a value to a parameter in your function call? Since there is no specification your IDE can’t help you look up parameter or function names.
Want to do a for-loop? Maybe some functions will support looping and other won’t, because looping is just a ` - loop-while: “a = b”` (or maybe it is double equal signs, who knows, because there is no actual IDE support.
And you ended up with some sort of half baked thing that was like a language but not. I get the same spidey sense when you look at how ansible uses YAML.
Ultimately I really do not care but it was a bad choice. I make bad choices all the time. I would expect the people who wrote Ansible do also.
We are actually seriously considering a shift to salt atm...
https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...
so at this point both ansible and salt can go both directions, and i do infact myself make use of that. i use pull/minions on all servers in our network, and push to those servers outside our network, because they can't reach the master behind the firewall.
although zerotier has helped solve that problem, so i'll probably be able to stop using salt-ssh soon
https://docs.saltstack.com/en/latest/ref/modules/all/salt.mo...
You can reuse all the playbooks and start scaling with salt.
i read that as: by the time ylu outgrow ansible, salt doesn't make sense either. but the next sentence seems to suggests to switch to salt when you outgrow ansible.
i always assumed that ansible and salt solve the same problems and when you outgrow one, you'd outgrow the other too.
E.g. seznam.cz (a Czech search engine) migrated from Salt to Ansible, they seem to cope ok. (There is a PDF from the LinuxDays talk last year.) Google Docs can translate PDFs even from Czech into English: https://pretalx.linuxdays.cz/media/Ansible.pdf
Templated YAML really isn't pretty to work with.
I use Ansible with zero issues daily as do many in our team. It’s perplexing coders fined it difficult or hard to use to the point where something as useful as Ansible becomes undesirable because it uses YAML?
I hate to say it, but the “alternatives” are just the least good somewhat similar products.