[zhynn]

While I have been a happy Ansible user for some time, the criticisims that the author pointed out that really resonated with me were:

- Ansible is slow even when it doesn't have anything to do. This is true. For example, we manage lists of former users that should not exist on systems, this gets quite slow. I think that the slowness is mostly due to SSH, but it could be smarter about bulk operations, I suppose.

- Custom DSL looping and conditionals. This was intended to make the system simpler and easier, but I agree with the author that I also have to revisit the documentation since looping in a template (jinja) is different than looping in a task (with_ directives).

- Task variable registration opacity. Yup, lots of debug: actions.

People in IRC are pretty friendly, but I did get a tone of "you're doing it wrong." This is exemplified, I think, by the author's "global ignore_errors" feature request. I made a suggestion that ansible-playbook should be able to run a role without having to create a stub playbook that calls the role. I ended up creating a bash script for it, but the response on IRC was in the vein of: I don't use it that way, you are doing it wrong. To me, Ansible is another tool in my sysadmin chest, I am going to use it in the way that works best for me. It's nice if the tool supports my workflow.

The remarks about the friendliness of the Salt community are enough to get me to take another look... Oh, and also that Salt released its webUI (Halite) to the community, but Ansible's AnsibleWorks is closed. A UI can go a long way towards increasing usage.

It's lightyears better than Puppet/Chef, and I am glad both exist. :)

[mpdehaan2]

So I think we do believe in teaching users the way to use the tool, rather than making every possible request in cases where things aren't clear. And that usually means making the docs self-convey what those ways are.

When you get to a project of Ansible's size, yes, we do have to be pragmatic about what we spend time on, so we like to look for patterns. if something gets heard from 15 times, it's definitely a thing. If something gets heard from once, we're most likely going to show the idiomatic way to do something in Ansible.

AnsibleWorks is actually not our company name, it's just "Ansible, Inc", and yes, our UI is closed source. But that allows us to hire a ton of people to work on it too, and I think we've made the right choice. I wanted our company to not become a support firm or a consultancy, and focus on products, such that we would always be motivated to keep the tool as easy to use as possible. The product thing is the natural place to take it in that case.

It's still free to use for 10 servers forever, and I think most of our users think we made the right choice there.

As for slowness, do check out the blogpost linked below, though upgrades for particular modules are always welcome.

I do think the custom DSL was 100% the right choice, as Ansible is a 100% valid data format, machine parseable, rather than something that only evaluates as YAML, and is not parseable.

Try "-v" if you'd like to see output without the debug, though the idea about having a "verbose: True" on the task might save some output. I'll think about that one.

[vacri]

If you think ssh negotiation is the slow point with ssh, have a look into 'persistent connections'

The below is an example setup of a session that persists for ten minutes after last logout. Subsequent ssh attempts (or new parallel ssh attempts) will piggyback onto the session and avoid the renegotiation delay.

  host *
    ControlPersist 10m
    ControlPath ~/.ssh/master-%r@%n:%p
    ControlMaster auto

[ryan_lane]

Hi. I'm the blog post author. The issue isn't SSH. I was running ansible-playbook on the local system using -c local. It wasn't using SSH at all.

[mpdehaan2]

Here's a rollup of lots of things you can tune:

http://www.ansible.com/blog/ansible-performance-tuning

[crdoconnor]

I would add that the default output is a bit kludgy.

Rendering output to JSON is super annoying when your commands have lots of '\n....\n....\n....\n....' in them and you're trying to find the "line" where the relevant error message appeared from the command called by your state.

Also, there are some messages (e.g. ssh key verification failed) that require a higher level of verbosity than they should for the correct error to appear.

Still light-years better than puppet or chef though.

[mjfisher]

> It's lightyears better than Puppet/Chef, and I am glad both exist. :)

I'm pretty new to the world of CM, and have just started playing around with Chef and Vagrant. I've been pleasantly surprised by the utility of Chef (i.e. miles better than setting up machines by hand or shell script and worth the learning curve).

Are there any particular areas of weakness when compared to Ansible/Salt/etc.? I've read a few Chef vs. Ansible vs. Puppet style blogposts, but they never seem to come to particularly strong conclusions.

[JustinGarrison]

From experience here is some of the CM tool downsides that might help you

Chef - Ruby DSL is hard if you don't know Ruby. Lots of infrastructure to manage (if not using hosted Chef). On the fly orchestration requires 3rd party tools or Enterprise License.

Puppet - Custom DSL is json-y which for some is easier than Ruby. Scaling problems because puppetmaster compiles the manifests (instead of having nodes compile). 2 tools/interfaces for config vs orchestration (mcollective) gets confusing and not very consistent with features.

Ansible - pretty much a lot of what the article said. A bit slow and custom loops/dsl sometimes gets confusing. Managing hosts file is mostly the only "infrastructure" you need, but still is annoying. No Windows support (yet)

Salt - Not as mature so it can't do some advanced stuff Puppet/Chef can do. Last I looked at web UI (Halite) it was not much to look at. Hardly any integration into 3rd party tools (most favor Puppet)

Don't get me wrong, I love CM tools and the pros list would be 1000x longer than cons. But they all have some big downsides that hopefully will get better in the future.

[mpdehaan2]

Sorry to keep replying to this one - slight correction on recent Ansible windows support if interested:

http://docs.ansible.com/intro_windows.html