Salt vs Puppet, Chef, CFengine, etc

[Zippy Zeppoli]

Hi List,
I am wondering how Salt compares to Configuration Management frameworks.  Please excuse me that I know very little about Salt, and look forward to being educated about it's differences from other available options, and how it fits into the infrastructure; the purpose of this thread.

Salt seems to me like more of a distributed command execution framework more than a configuration management system.
When I first saw Salt, I thought it to be very similar to tentakel (http://sourceforge.net/projects/tentakel/files/tentakel/tentakel-2.2/).

How is it different from tentakel for distributed command execution?
Also how does it fit in with use of other config management frameworks? Is it intended to be used in conjunction with, or instead of Chef, Puppet, etc?

Thanks,
Z

[David Bishop]

Salt is mcollective + puppet in one. So yes, you can use it as a config management system (it works very nicely as one). You can also use just the remote execution portion, and continue using puppet/chef/etc.

-- 
David Bishop

[Thomas S Hatch]

Salt builds configuration management on top of the remote executions system. The philosophy is that the two aspects of system management are fundamentally linked. Salt is also intended to be fast, easy to use and lean, lightweight and easy to set up.

Salt differs from other remote execution systems because it is built on ZeroMQ instead of and AMQP system or SSH (like tentakel). This difference makes Salt much faster and lighter weight than SSH based systems. As for configuration management, Salt is made with the goal of being easier to get going. Many community member have been able to pick up Salt quickly and have expressed that it is easy to learn and maintain.

Please feel free to send us more questions on this matter.

- Thomas S Hatch

[Jacob Albretsen]

On Monday, June 11, 2012 05:47:32 PM Zippy Zeppoli wrote:
> Hi List,
> I am wondering how Salt compares to Configuration Management frameworks.
> Please excuse me that I know very little about Salt, and look forward to
> being educated about it's differences from other available options, and how
> it fits into the infrastructure; the purpose of this thread.

1 - I would also say the Salt community is great. The Puppet community was
nice enough when I interacted with them on IRC, but something is different
about the Salt community. Ideas and suggestions are met with enthusiasm and
often added to the "todo list".

2- I am surprised, given its age, some of the things Puppet didn't do that
Salt can do or have been added to the todo list.

3 - YAML for Salt states is a heck of a lot easier to read, write, and
understand than Puppet modules. And once you get jinja templating figured out,
you'll be unstoppable.

4 - Keys are easier to handle in Salt than in Puppet. 85% of the time, keys
in Puppet were not problem, but the other 15% of the time I pulled my hair
out. I was reinstalling a test box multiple times for various reasons and
there would be one time that I could not get the key from the previous install
to completely go away. I'd have to resort to manually editing the files in the
ssl directory to get it to go away so it would accept the new key. And if the
time on your puppet master and client are too far off for some reason, it won't
even work and gives you no clue as to why.

[Zippy Zeppoli]

This answers my question as well. Thank you.
I am still curious to know, how easy is it to create new SLS's, for example if I create an entirely new web server (not that I would) with some new configuration file.

How can you set up rules for remediation problems, for example, to automatically remediate, or just to trigger an email alert?

[Thomas S Hatch]

A new web server? That should be very easy:

nginx:
  pkg:

    - installed

  file.managed:

    - source: salt://nginx/nginx.conf

  service.running:

    - watch:

      - pkg: nginx

      - file: /etc/nginx.conf

What scope do you have in mind for remediation? Like fixing a changed config file? The watch statement in this code will do that work, let me know if you mean something else.

[Zippy Zeppoli]

Hi Thomas,
Thats exactly  what I meant, thank you.
But with apache, you can manage individual elements of a config file such as httpd.conf, no?
I was wondering if you created your own app, per say, could you define a way to manage individual elements of a config file? Macros if you will.

[Thomas S Hatch]

Not from within the sls data directly. I would like to have an apache state with that level of granularity. Right now the best way to do this would be to use jinja templates on the http.conf file. I would sperate out the http.conf file with jinja statements and then you can pass data to the jinja template via the sls data:

/etc/httpd/conf/httpd.conf:

  file.managed:

    - source: salt://apache/httpd.conf

    - virtual: True

so the values you pass in the sls become jinja variables, in this case your config file could have a jinja if statement checking for virtual and then adding info to the config based on this