So, after working with Ansible over the last 7 months, I've come to the conclusion that it's not SO bad (it is still bad) if you have some sort of frontend to i

So, after working with Ansible over the last 7 months, I've come to the conclusion that it's not SO bad (it is still bad) if you have some sort of frontend to it that builds your playbooks for you and then calls out to `ansible-playbook` instead of trying to write your playbooks from scratch in YAML. We have a big CLI application, written in Python, that does a lot of this for us. It provides clean, specific interfaces to our most common tasks and has wrappers around the base tools (`ansible` and `ansible-playbook`) that add some useful features we found missing from the base tooling (Want to set a nested variable without resorting to passing a JSON dictionary at the command line? `-V foo.bar.baz value`). Even though our CLI is written in Python, we still prefer to build and write playbooks to temp files before calling out to `ansible-playbook` over the Python API just due to the amount of logic baked into the module and playbook runners that we'd have to replicate ourselves. Ansible 2.0 looks to provide a more powerful Python API (and a better example on how to use it in the docs), but porting our stuff now isn't really a priority. As I started writing this, I thought this would be a much more scathing comment as I find myself terribly frustrated on a regular basis, but, as I said, it's not SO bad using a frontend written in a language I enjoy working with. As another commenter wrote, I really feel that Lisps/Schemes (or some other language with a powerful macro system) would make the ultimate ops/cms languages...Guix and Pallet seem to be the only games in town in that regard.