Why Saltstack is Better

[Stephen Wood]

In preparation for a discussion about configuration management at my company, I've been gearing up for a strong push to use Saltstack over Puppet and Chef. I've written something I call "Why Saltstack is Better" that I'd like some feedback on. It's included in this email.

Can you guys share any other reasons I might use in my discussion that would persuade Saltstack over Puppet and Chef? Are these points valid? Are there other valid points?

Why Saltstack is Better

Saltstacks is a powerful and robust remote execution tool

Saltstack started its life as an execution tool. It gives you the ability to execute commands across thousands of servers with scalpel precision.

Saltstack employs a job id system. Jids can be referenced and tracked after they are executed. They are even stored in history and can be referenced later.

Saltstack employes zeromq to send out messages. This means that it is very scalable since the saltmaster is not opening up thousands of SSH sockets with minions. This is an important distinction to other tools such as capistrano, which are bound to fail during large deployments or when network connectivity is spotty. Plus, because of the jid system, you can keep track of what's running, what's failed, what's succeeded, and what's finished.

Saltstacks using simple ssh keypairs for authentication.

No juggling SSL certificates. Each host has a private and public key. Using these keys both the master and the minion can verify the identity of the other.

Saltstacks configs are stored in a readable yaml format

Unlike both Chef and Puppet -- which requires configurations in a Rubyesque syntax -- configurations in Saltstack are yaml and very easy to read. You can also use simple yaml parsing programs to check the syntax of your configuration file.

Saltstack provides top-down execution order in configurations

This is something that drives a lot of people insane when using Puppet. Puppet manifests are executed in an declarative way that seems to just jump all around the manifest, so you end up writing dependencies for all sorts of executions. This leads to significant bloat of config files as well as some serious headaches when attempting to troubleshoot manifests. 

Salt configs on the other hand are imperative and will execute from the top down in an SLS file. This helps greatly when porting over bash scripts. It also means you don't need to write requirements for any declaration, leading to slimmer and easier to write configuration files.

Saltstack has a lively and active development community

Saltstack is the new kid on the block and is generating a lot of buzz. Unlike both Chef and Puppet, the salt community is lively and active. Mailing lists are busy and users on the irc channel are quick to offer help. This makes a huge difference when getting help.

Saltstack will not try and sell you hosting

This was something that always bugged me about Chef. There is no paid hosting with Saltstack. Everyone gets the same thing and you won't be pushed into pricing models.

--

Stephen Wood

www.heystephenwood.com

[Joe Healy]

My thoughts below:

On Wed, Oct 09, 2013 at 08:59:47PM -0700, Stephen Wood wrote:
> Saltstack employes zeromq to send out messages. This means that it is very
> scalable since the saltmaster is not opening up thousands of SSH sockets
> with minions. This is an important distinction to other tools such as
> capistrano, which are bound to fail during large deployments or when
> network connectivity is spotty. Plus, because of the jid system, you can
> keep track of what's running, what's failed, what's succeeded, and what's
> finished.

I'm not sure you can draw these distinctions about potential failure
when the network is spotty. If the network is spotty, I suspect
anything may struggle.

I do think a key point is that the minion connects to the master then
waits for commands. No need to have sockets open on the minion.

>
> Saltstacks using simple ssh keypairs for authentication.
>

Keypair - yes, ssh keypair no. At least on my system they are RSA
keypairs.

> No juggling SSL certificates. Each host has a private and public key. Using
> these keys both the master and the minion can verify the identity of the
> other.

Hope that helps,

Joe

[Shawn Milochik]

If you are a Python shop, then the fact that it's Python and not Ruby is a great selling point.

Also, from my limited experience with Chef, Salt is so much simpler to learn and get started with than Chef. 

[Dmitry Golubenko]

В Срд, 09/10/2013 в 20:59 -0700, Stephen Wood пишет:

> In preparation for a discussion about configuration management at my
> company, I've been gearing up for a strong push to use Saltstack over
> Puppet and Chef. I've written something I call "Why Saltstack is
> Better" that I'd like some feedback on. It's included in this email.
>
>
> Can you guys share any other reasons I might use in my discussion that
> would persuade Saltstack over Puppet and Chef? Are these points valid?
> Are there other valid points?

I'd add different available transports (0zq + ssh) PLUS awesome
`salt-call' functionality to do things from minion-side PLUS various
'bonus' subsystems like returners, mine, reactor, ... available 'for
free' and integrated with base state and remote command execution

[Sebastien Wains]

If you need to "sell" Salt to technical people, the hands-on lab approach (which I did at work) works great.

We started with empty VM's and 45 minutes later we were already deploying Apache configs (so we went through master/minion install, salt key management, folders structure, first simple state).

At the end I said "Soo.. easy, eh ?". A colleague (with an experience with Puppet) was like "No kidding !".

[Dmitry Malinovsky]

One sentence totally describes Salt (well, at least for me and my company): "Great contribution in the beginning - a great benefit in the process."

[martin f krafft]

You were looking for advantages of Salt. I am sorry to be playing
devil's advocate, but Salt isn't quite there yet…

also sprach Stephen Wood <smw...@gmail.com> [2013.10.10.0559 +0200]:

> Saltstack employes zeromq to send out messages. This means that it is very
> scalable since the saltmaster is not opening up thousands of SSH sockets
> with minions.

I don't see this as a problem, unless of course you open a new SSH
connection for each command. But other than that, there is no real
difference at the socket level between thousand minions having
a zeromq connection to the server, or the server having a SSH
connection open to minions.

In fact, I know you are looking for good things about Salt, but here
are two bad things:

1. it uses zeromq and then provides its own crypto transport
layer, which has had security issues in the past. salt-ssh
solves that a little bit, but not in a scalable way;

2. the master does not know which minions are connected at any
given time. A job is published to connected minions and whether
a minion executes it, is a decision made by the minion. There
is no way to find out whether a given job executed on all
minions where it should have been executed.

> Saltstacks using simple ssh keypairs for authentication.

It does not. It implements its own X.509-based PKI. salt-ssh uses
SSH keypairs, but Salt itself does not.

> Unlike both Chef and Puppet -- which requires configurations in a Rubyesque
> syntax -- configurations in Saltstack are yaml and very easy to read. You
> can also use simple yaml parsing programs to check the syntax of your
> configuration file.

The loose, multi-purpose YAML-format also means that syntax errors
cannot be easily found, unless they are YAML-syntax errors. There
are plenty of ways in which spacing can change behaviour, all of
a sudden, and still be perfectly legitimate YAML.

Plus, do you know the rules when to use key-value pairs, and when to
use lists?

Salt provides no syntax checker. There are benefits to
domain-specific languages with strongly enforced syntax rules.

> Saltstack provides top-down execution order in configurations

> […]

> Salt configs on the other hand are imperative and will execute from the top
> down in an SLS file.

It does not. Recipes are executed in random order (depends on the
sorting of Python dicts). You have to specify relationships just
like with Puppet to get a defined order.

> Saltstack will not try and sell you hosting

Promise? ;)


also sprach Joe Healy <joeh...@gmail.com> [2013.10.10.0610 +0200]:

> I do think a key point is that the minion connects to the master
> then waits for commands. No need to have sockets open on the
> minion.

Except now you have a port open on the master, which is a big
security risk.


But yes, Salt definitely beats Puppet and Chef by many many lengths.
I only hope that all those petty problems get resolved at some
point.

See also:
http://madduck.net/blog/2013.02.01:a-botnet-for-configuration-management/

--
martin | http://madduck.net/ | http://two.sentenc.es/

"i started taking an online a.d.d. test, linked from
someone's blog. i never finished it; i got distracted, and clicked
on random other shiny things"
-- andres salomon

spamtraps: madduc...@madduck.net

[David Bezuidenhout]

Just to double check on one of your comments Martin:

On Thu, Oct 10, 2013 at 12:41 PM, martin f krafft <mad...@madduck.net> wrote:

> Saltstack provides top-down execution order in configurations

> […]

> Salt configs on the other hand are imperative and will execute from the top
> down in an SLS file.

It does not. Recipes are executed in random order (depends on the
sorting of Python dicts). You have to specify relationships just
like with Puppet to get a defined order.

Looking at the release notes of 0.17 @ http://docs.saltstack.com/topics/releases/0.17.0.html

State auto order was introduced using the order of the definitions in the sls file?

I quote:

State Auto Order
This is a major change in how states are evaluated in Salt. State Auto Order is a new feature that makes states get evaluated and executed in the order in which they are defined in the sls file. This feature makes it very easy to see the finite order in which things will be executed, making Salt now, fully imperative AND fully declarative.
The requisite system still takes precedence over the order in which states are defined, so no existing states should break with this change. But this new feature can be turned off by setting state_auto_order: False in the master config, thus reverting to the old lexicographical order.

 

[martin f krafft]

also sprach David Bezuidenhout <tin...@ipv6.za.org> [2013.10.10.1248 +0200]:

> Looking at the release notes of 0.17 @
> http://docs.saltstack.com/topics/releases/0.17.0.html

I stand corrected. I have not yet had time to look at 0.17 ;)

Nice!

--
martin | http://madduck.net/ | http://two.sentenc.es/

this space intentionally left occupied.

spamtraps: madduc...@madduck.net

[Mike Ainsworth]

Just a quick note regarding:

> 2. the master does not know which minions are connected at any
> given time. A job is published to connected minions and whether
> a minion executes it, is a decision made by the minion. There
> is no way to find out whether a given job executed on all
> minions where it should have been executed.

because of the event driven nature of salt, it actually does do this. Not automatically in it's purest most-vanilla form as you have to run salt-run manage.up or salt-run manage.down, but for example the Halite console runs this runner automatically gives you "red/green" up or down real-time status. This can also be used for knowing which minions correctly ran or failed a given job.

[martin f krafft]

also sprach Mike Ainsworth <michael.b...@gmail.com> [2013.10.10.1749 +0200]:

> because of the event driven nature of salt, it actually does do
> this. Not automatically in it's purest most-vanilla form as you
> have to run salt-run manage.up or salt-run manage.down, but for
> example the Halite console runs this runner automatically gives
> you "red/green" up or down real-time status. This can also be
> used for knowing which minions correctly ran or failed a given
> job.

I am talking about https://github.com/saltstack/salt/issues/2361 and
even though I know I can use Salt for monitoring as you suggest,
it's not quite the feature I want.

--
martin | http://madduck.net/ | http://two.sentenc.es/

consciousness: that annoying time between naps.

spamtraps: madduc...@madduck.net

[Thomas S Hatch]

Stephen, on the hosting thing, the better way to say it is to talk about how Salt is not Open Core, and Salt is the only company in the space that is not open core. As for selling hosting, we do have partnerships with cloud providers in place where this is a consideration, but the real issue here again is the fact that a hosted Salt would still be open source Salt, and not an open core offering.

Thomas S. Hatch  |  Founder, CTO

5272 South College Drive, Suite 301 | Murray, UT 84123

tha...@saltstack.com | www.saltstack.com

[Shane Gibson]

Stephen,

I read through your document, and I have to say ... it reads exactly like someone trying to blindly justify SaltStack.  I understand the need to make an internal justification, but I would highly suggest you approach it from the stand point of "Salt" compared to "Puppet" compared to "Chef" compared to "Ansible", etc.  

You list all the "great things" about SaltStack, but give no context about the comparison to the same/similar/lacking features in the other DevOps tools.  I suspect there is a tremendous body of experience and knowledge in this community that can help with making a broader comparison of SaltStack to the "competitors".  Maybe if you drew up a matrix of all of the great things about SaltStack, and filled in the comparison analysis to Puppet/Chef/etc, and asked for community involvement to finish it off, you might end up with an excellent document to objectively compare them.

Right now, even though I like SaltStack's architecture and am strongly interested in it - your document reads like someone pleading to like the toy you chose.  Please note, I'm not trying to put you down or be negative - just feel that you'll be much more successful with a more objective approach to the comparison of the tools. 

I for one ... would absolutely love an in depth comparison of the architectures, features, and capabilities of the more well known DevOps tools.

~~shane 

[Shawn Milochik]

I think Shane's suggestions are very good. I did a "lunch and learn" with my department and demoed a fully-working Salt deployment of a server running one of my company's SaaS applications. Then we walked through the "code" and I explained how it worked. That gives people familiarity, and familiarity brings comfort and trust. 

[Les Mikesell]

On Thu, Oct 10, 2013 at 2:07 PM, Shane Gibson <sygi...@gmail.com> wrote:
>
>> I for one ... would absolutely love an in depth comparison of the
> architectures, features, and capabilities of the more well known DevOps
> tools.

You almost never see good comparisons of complex tools because no one
has the time to learn all their tricks. If someone even uses more
than one it is because they ran into some specific problem with the
first one they tried and that's the feature that determined their next
choice. I'd like to see the opposite of the 'feature checklist
grid' that everyone uses for comparisons, though: that is a grid
showing what is bad/difficult/impossible with each instead.

--
Les Mikesell
lesmi...@gmail.com

[Stephen Wood]

Thanks for the feedback, Shane. In response to what you wrote, that is precisely why I've opened it up for feedback and discussion here. :)

--

You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Stephen Wood

www.heystephenwood.com

[Colton Myers]

  2. the master does not know which minions are connected at any
     given time. A job is published to connected minions and whether
     a minion executes it, is a decision made by the minion. There
     is no way to find out whether a given job executed on all
     minions where it should have been executed.

This is only partially true.  No, the master does not keep track of minion connections, so it may try to publish a command to a minion that is offline.

However, new functionality (introduced for the 0.17.0 release) made it so that the master no longer broadcasts commands to all minions, and then waits for whoever wants to return to return.  Rather, it compiles a list of "expected minions", and only waits for minions in that list to return.  (I'm unsure of whether it still broadcasts the command to all minions -- I'll have to check that out)

This also means that if you run a command with the verbose flag (-v or --verbose), it will tell you which minions did not return that were expected.

Anyway, just wanted to clarify this point.

--

Colton Myers

[Ajith Antony]

On Thursday, October 10, 2013 2:33:42 PM UTC-5, LesMikesell wrote:

On Thu, Oct 10, 2013 at 2:07 PM, Shane Gibson <sygi...@gmail.com> wrote:
>
>> I for one ... would absolutely love an in depth comparison of the
> architectures, features, and capabilities of the more well known DevOps
> tools.

You almost never see good comparisons of complex tools because no one
has the time to learn all their tricks.  

FWIW, there is this http://devopsu.com/books/taste-test-puppet-chef-salt-stack-ansible.html 

Not a deep dive into each product, but it's pretty good place to start.

[Stephen Wood]

Looks like that's a $39 book?

--

You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Stephen Wood

www.heystephenwood.com

[Ajith Antony]

On Thu, Oct 10, 2013 at 6:45 PM, Stephen Wood <smw...@gmail.com> wrote:
> Looks like that's a $39 book?

Pricing a book like this is pretty complicated. The audience is very
small so pricing it very low may not lead to enough sales to justify
the research and production cost.

It is pretty costly relative to books at large. But could also be
very valuable to you. There does not exist another book that is as
current, and focussed on this specific analysis. For some this could
save many hours of experimentation, googling, reviewing potentially
outdated docs and blogs. If you aren't familiar with one or more of
these tools, and are seriously considering evaluating them, then it is
worth it.

If you subscribe to his mailing list he might send you a coupon or
something. When he released it I think it was $27 for the mailing
list people. Or if you email him he might just give it to you. In my
feedback, to him, I did mention that it was priced kinda high, and he
offered to refund me (i declined the refund).

[Stephen Wood]

I have no qualms paying for good quality literature. I was just wondering if I was on the right page.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Stephen Wood

www.heystephenwood.com

[Dan Garthwaite]

Jinja everywhere.  

This really was a deal maker for me, coming form Fabric.  The idea that everything in UNIX is a file, thus with salt every file, everywhere, is a jijna template waiting to happen.  Throw in the event system to trigger these states and you can start to see your systems dance.

[schlag]

yes!  we really do need to have better documentation on features like this.