Chef needs to be installed, but it can be (easily!) run in an agentless mode via chef-solo or chef-zero. It can be installed from Rubygems and requires no master node.

I think using sshkit and chef-solo you could easily achive the agentless model ansible provides with a more mature toolset and community. I never really understood peoples aversion towards agents though. You literally can create a golden image with chef-client and your done. There is very little cpu or memory overhead from the chef-client and it only runs when requested unless you run it in daemon mode. I think Ansible capitalized on people's wariness/lack of experience using chef rather than there experience causing them to look for an alternative.

Sure, even salt supports an agentless mode, but these are designed as afterthoughts. When you look at all the agentless mode versions of these tools you find that it doesn't fully support everything the framework is capable of (i.e., see the main page of chef-solo). Thus, the adoption is low and you'll likely find breakage as the tool matures (new features being developed without consideration of the audience using it in an agentless mode) and you're likely to find little help when you ask for it. Contrast this with ansible, where this is the basis of the framework, so everything built around it works in agentless mode.

So no, nobody is saying you can't run chef/salt in agentless mode, but in practice nobody wants to because it's a lot of work. And it's not like ansible doesn't also run in a managed-by-master-node mode, that's the entire basis of ansible tower.

And to be clear, it's not that I like ansible because it's agentless. It's because the benefits of the tool being designed-from-the-ground-up as agentless leads itself to beneficial properties.

> You literally can create a golden image with chef-client and your done

This is a lot more work than you let on. That client needs to be configured to point to a particular master node. So yes, you can create a golden image, and it'll talk to one master node, and run on one platform. Good luck getting your golden AMI to run locally in VMWare, or virtualbox, or in a LXC container. Good luck adding in the functionality to make your client dynamically select a different master. It's not impossible, it's just not dead easy. The fact that this is an annoying thing to do is proven by the existence of salt-bootstrap (it's a tool that SSH'es into a node and sets it up as a salt client, hrm, now where else have we seen a tool that manages a node only using ssh?)

> I think Ansible capitalized on people's wariness/lack of experience using chef

I think this is a rather unfair generalization to make. I've personally had many years of production experience with chef/puppet/fabric and the only reason I have no actual production experience with salt is because ansible came out soon after (I still follow their development with interest). In my experience, the people I know who use ansible are neckbeard admin types with battle scars from other orchestration frameworks.

I use SaltStack masterless extensively. It works very well. It's not an after thought and numerous salt contributors use salt in a masterless setup.