I have pretty extensive experience using Salt very deeply, and while it's good, I recommend it only with some pretty severe reservations.
First is that management of the master is still a big, big pain point. Unless something's changed in the last few months, you can't meaningfully cluster a salt master. Minion keys must be accepted on each master in turn. Auto-accepting minion keys is risky as hell, too. Master signing keys sound like a great idea until you realize that it means you can't bootstrap a minion sui generis.
My other big problem with salt is that Salt formulas are really popular, but are _completely_ uncomposeable. Time and time again I found places where the action of a formula needed to depend on data that existed elsewhere in the pillar, but pillars can't be parameterized with pillar data (obviously). They're also not versioned at all, so occasionally breaking changes are merged in (I myself am personally guilty of doing this). The idea is a decent one ("separate the data from the code!"), but they end up being a real headache in a complex environment.
There are a few other, more minor, issues I had with Salt, but really my main beef is that Salt is an extraordinarily effective footgun. If you try to avoid writing "salt scripts" (think: Ansible playbooks), it's very, very easy to end up with a really messy dependency tree, crazy templates, etc. Yes, I know that discipline matters, but people aren't perfect.
I agree with most of your points, but having used other systems, I just have to point out that all configuration management systems are footguns that give you armor over 50% of your foot, and let you aim how you please.
I think salt helps to enforce that you can't arbitrarily compose disparate datasources with overlapping namespaces and have it magic it's way to a sane solution.
Chef tries to compose its data via a very sensible yet hard to get right ordering mechanism. Salt says "nope, you overlap, it breaks, and you get to fix it". I prefer salt's approach but what I like more is the temptation to write an external pillar provider that will do the right thing for me when I get to that point. It's imperfect but quite powerful.
I've used Salt extensively, and found it unbelievably buggy. I'm not sure the company behind it tests it in any way, and you can expect terrible bugs in every point release.
Their bug tracker (which is 3500 open issues deep) has to be treated as documentation, and the real documentation is often a work of fiction.
I had bought into it originally because it claimed some Windows support. It did have it. But it was very limited and bug ridden. I really wanted to like it, but it just fell down at every step. Worked ok-ish on Linux systems though.
That's weird. We have used salt to manage hundreds of machines for a few years and have had no issues with bugs. However, we are only using it with ubuntu so that may be a reason we haven't encountered the bugs you speak of.
I will note that the zmq layer very occasionally seems to loose connections and you need to ssh into a machine and restart the salt minion, that's the only issue I've seen.
We use salt extensively and I have reservations even though I like it.
It has a fairly nice configuration management language at its core, but it brings so much baggage with it that it's completely overwhelming. They can't figure out what they want to do with the project, so they do a little of everything.
The sheer number of concepts and awkward terminology you have to learn to use it are off-putting. I've had to drag a couple devs along for the ride and the learning curve is big impediment to further adoption in our org.
No, an agent runs on the host (a "minion") and calls back to a ("master") for instruction. Masters pub messages to minions with job IDs, and minions execute and respond accordingly. The minion is very lightweight. Masters less so, but they vertically scale pretty well.
