> You seem to have a serious down on the whole concept behind Ansible, and I'm curious why that is. No, not really. Not on the high-level idea(s). Heck, I've w

> You seem to have a serious down on the whole concept behind Ansible, and I'm curious why that is. No, not really. Not on the high-level idea(s). Heck, I've written myself (or at least deployed already-written) tools for what Ansible tries to do: configuration management, synchronous mass running an ad-hoc command on a set of machines, and running a specific, parametrized procedure on a single host. I recognize all these scenarios are important and I want to have tools for each of those, but let the tools do these jobs robustly. What bothers me is design decisions and architecture of Ansible (and other tools sharing them). The decisions seem sound from far away, but they start leaking once you look closely. Good general tool would be robust for pretty much all the use cases; Ansible is brittle (breaks when you misconfigure sshd_config a little; breaks when you accidentally overwrite SSH keys; can't work if you don't have account with working shell and $HOME; breaks apart when some of the hosts are down; and so on). Ansible apparently started as a script that automated somebody's workflow (which is a good thing) -- and stayed that way, but now is marketed as a general tool (which is not, but resembles it closely enough to trick many its users into thinking it is). It all boils down to Ansible still being a quick hack for somebody's specific workflow and me hating buzz around half-assed tools. > Have you had a bad experience with it? If so, I'd like to hear about it, in order to better inform my own analysis of the tool. I have so many objections against Ansible (some I mentioned above) that it actually makes more sense to write a separate article about it, but this will take time.