Hacker News Reader

Comment by kev009 | Hacker News Reader

I've generally seen the opposite, salt works well multi0-platform, ansible is geared toward the LTS distros. It's extremely easy to get bug fixes into salt, and I've done a few dozen.

The biggest issue I see with ansible is the amount of discipline required to use it well. Junior staff will create non-idempotent plays. I don't really see that with salt, where shelling out is pretty rare (the benefit of NIH?).

View on HN

SaltStack is famous for their NIH syndrome and various high severity vulnerabilities that have resulted from that.

I've used both Ansible and SaltStack a fair bit and would agree with the parent. In most cases, Ansible w/ Mitogen is the way to go.

SaltStack is really only sanely deployable in a Masterless setup. Also the real secret sauce of SaltStack that almost no one is using it for is its Event Bus & Reactor System to automate maintenance/incident runbooks. There's a ton of untapped potential there.

I always am curious when I see this. I've planned and deployed master setups in two separate 10^4 node count companies now. In my experience the number of hosts doesn't really matter (figuring out an architecture that will work with availability zones etc only takes a couple weeks). The real work is figuring out how to normalize and govern the repos. I haven't seen any sane ansible repo once it's beyond a few senior contributors because it's so easy to do whatever you want. Ansible is the ultimate small business tool, but it works very poorly in large companies.

We're at the 10^4 node count but the team managing it is still at the 10^1 size. That's how, basically. You have to make large investments into automation, code review process and time to make continuous improvements (because things do slip through).

There's style guides, linting, commit checks...

Reply on news.ycombinator.com