It layers a custom DSL on top of a perfectly adequate language, uses standard terms like classes in non-standard ways, takes away the linear top/down flow that most programmers are used to, forces sequencing through notification chains, steamrolls over error messages willy-nilly, etc. Although I'm a bit biased so a few more data points would be helpful.
I notice none of these problems on a 3.2 deployment with about 500 nodes.
I find that Ansible is roughly identical doing the same things on the same machines timewise, not going to get into the subjective argument about the language, the parser syntax is backwards compatible between major releases (and they go well out of their way to warn you what you'll need to change before something actually does break), and I don't see how it's any harder to test locally than any other config management tool.
This isn't true as of more recent releases (since around ~3.0), they appear to have finally gotten their act together.
> really hard to test locally
Tools like Beaker are finally the norm, so I've high hopes for this improving over the coming year.
But yes, crazy slow alone destroys everything. Typical "fixes" include going masterless, yet there's no standardised distribution methods so you need to invent that yourself. Embedding all files into catalogs, thus turning network overhead into CPU overhead etc.
Not to mention in the insane memory usage client side, i.e. on every single box.
