3 ms·

This article, like so many others, makes an assumption that Salt is the 4th place configuration management tool. It is not, it is a python orchestration framewo

by tapoxi 6y ago

This article, like so many others, makes an assumption that Salt is the 4th place configuration management tool. It is not, it is a python orchestration framework that just happens to have a configuration state module. Deployments I've written in Salt just use the Python API (https://docs.saltstack.com/en/latest/ref/clients/ https://docs.saltstack.com/en/latest/ref/clients/) to make changes to machines or infrastructure. That's the power of it, and unfortunately its terribly underutilized. There are legitimate criticisms of Salt of course. There's a lot of moving parts, there's a lot of half-baked stuff, the crypto has been questioned, but the core idea is honestly pretty great and its always been a pleasure to work with.

npsimons 6y ago
I chose salt after failing to get Puppet and Chef working. Out of the box on Debian, just no luck. Salt was just plug and go. Haven't bothered with Ansible (yet) as it didn't officially support states when I was evaluating options, and statefulness was my number one need. I can pick up languages fairly easy (I'm a software dev by trade), so different languages don't bother me, it was more about feature set. It is annoying, though, that it seems everyone treats Salt as forgettable. I wish I could find things like https://github.com/dev-sec https://github.com/dev-sec for Salt, but they only have Ansible, Puppet and Chef versions.
curryst 6y ago
> It is not, it is a python orchestration framework that just happens to have a configuration state module. I've seen small pieces of utilization like this that looked awesome. I totally agree with the sentiment. > There are legitimate criticisms of Salt of course. There's a lot of moving parts, there's a lot of half-baked stuff, the crypto has been questioned, but the core idea is honestly pretty great and its always been a pleasure to work with. I could deal with that, but I have had absolutely misery trying to stabilize Salt minions. I had constant issues with them crashing or just hanging. Complexity is manageable, I can work around the parts that aren't totally there yet, I can live with maybe insecure crypto, but I can't have any stage of the deployment pipeline be flaky. It's annoying for me because I have to fix it; it's annoying to the people that need to deployments because they can never tell if their pipeline will succeed or not, and they have to wait on me to fix it. It ends up building a lot of animosity towards the tool, and by association, to the team that introduced it. I just use Ansible now. It's not nearly as powerful (the ability to drop into Python in Salt is really nice, and I find equivalent things difficult to write in Ansible), but it pretty much always works. The abstractions are messier, but at a certain point, the less powerful but stable solution just makes more sense. I really hope Saltstack can turn around on their reliability, because I would love to use it again.

by tapoxi 6y ago

npsimons 6y ago

I chose salt after failing to get Puppet and Chef working. Out of the box on Debian, just no luck. Salt was just plug and go. Haven't bothered with Ansible (yet) as it didn't officially support states when I was evaluating options, and statefulness was my number one need. I can pick up languages fairly easy (I'm a software dev by trade), so different languages don't bother me, it was more about feature set. It is annoying, though, that it seems everyone treats Salt as forgettable. I wish I could find things like https://github.com/dev-sec https://github.com/dev-sec for Salt, but they only have Ansible, Puppet and Chef versions.

curryst 6y ago

> It is not, it is a python orchestration framework that just happens to have a configuration state module. I've seen small pieces of utilization like this that looked awesome. I totally agree with the sentiment. > There are legitimate criticisms of Salt of course. There's a lot of moving parts, there's a lot of half-baked stuff, the crypto has been questioned, but the core idea is honestly pretty great and its always been a pleasure to work with. I could deal with that, but I have had absolutely misery trying to stabilize Salt minions. I had constant issues with them crashing or just hanging. Complexity is manageable, I can work around the parts that aren't totally there yet, I can live with maybe insecure crypto, but I can't have any stage of the deployment pipeline be flaky. It's annoying for me because I have to fix it; it's annoying to the people that need to deployments because they can never tell if their pipeline will succeed or not, and they have to wait on me to fix it. It ends up building a lot of animosity towards the tool, and by association, to the team that introduced it. I just use Ansible now. It's not nearly as powerful (the ability to drop into Python in Salt is really nice, and I find equivalent things difficult to write in Ansible), but it pretty much always works. The abstractions are messier, but at a certain point, the less powerful but stable solution just makes more sense. I really hope Saltstack can turn around on their reliability, because I would love to use it again.