Salt is unfortunately (in my two year old experience) full of features and strange bugs related to them - I do remember encountering a bunch of memory leaks master side for example. Deployment had the classic issues of python applications.

The core was (mostly) solid, but if you need anything done on it do buy the time of some consultant working on it already.

It's not as accessible as ansible, but definitely more accessible than cfengine. At least coming from Ansible.

I used Salt ~5 years ago, so things may have changed, but I wasn't impressed. In theory, it is an immensely powerful system. The broadcast system offers ways to orchestrate things in a way that's hard with eg Ansible.

The reality was that it was unstable, and use cases that needed the broadcast system were rare and often contrived. Agents crashed or hung constantly. We ended up mostly using the same features Ansible already had.

I might PoC it if I was going to deploy at a scale large enough where Ansible being centralized was an issue (i.e. there are so many hosts that it takes hours for Ansible to run). I'd have to see whether the pain of managing agents was better or worse than trying to shard Ansible. My suspicion is that it isn't too hard to shard Ansible deployments, but I could well be wrong, I haven't tried.

I used it and even took a class taught by salt stack employees.

I really was not a fan. I think one of the core problems I ran into was that the tool attempted to layer on rpc behavior to what was fundamentally a broadcast.

So you'd apply something to everything with a web role. The tool would attempt to make it appear as if you executed apply on n nodes and return after n responses. But since this was all just a broadcast what really happened is the tool dropped a message on the bus and then guessed how many responses it would get. If it guessed wrong the cli invocation would just hang.