Salt stack, the simpler puppet

We use saltstack at Zenpayroll.com to manage our servers, and I think it works pretty well. Not 100% sold on the jinja/python stuff, but it does the job.

I started looking at Salt and really liked what I saw, but the first task I had to do was to provision some Windows Servers on Rackspace or AWS and configure them. Like the other commenter, I wish I didn't have to deal with Windows but I'm stuck with it. I found Saltcloud a bit bleeding edge for a newcomer to configuration management (although improving all the time) with Windows being its biggest weakness. When it comes to configuration, it also seemed to me (admittedly with limited experience) the Windows support in Salt is a poor cousin rather than an equal citizen. Don't get me wrong, it's good they have it at all, but you'll need to do a lot more work yourself. I plan to look at Chef next as a possible alternative since the Windows support seems more mature. No comments on Chef yet so I'd be interested to hear anyone else's experience with it, especially for a newcomer to config management tools.

My main experience is with Puppet, though I have migrated legacy systems from CFEngine as well. My main gripes with Puppet are that, at times, the DSL is restrictive and you have to either rely on ugly Execs or dropdown into Ruby extensions. I can see how this can be off putting to beginners.

The advantages though once we've gotten comfortable have made our infrastructure smarter and more resilient.

- Idempotency (If you're careful)

- Abstracting configuration data vs methods. Passwords/Keys/Addresses are kept in a Hiera config file and the manifests merely access these variables instead of hardcoding when applying changes.

- PuppetDB as a canonical reference of the state of all our infrastructure. What are all my servers running MySQL? Which version? Where are all my Ceph MDSs?

- Exported resources (also relying on PuppetDB), enabling propagation of information about new nodes to all others. A godsend when paired with Nagios.

Does Salt have anything that matches these use cases?

- Idempotency

Yes, the run will report on each salt state which can result in either: failed (with a reason), succeeded (with a description what changed), succeeded (nothing changed). Each salt state provided by the project is also intelligent about its use of resources - for example, if you have multiple pkg.installed, the list of available packages will be pulled only once and all states will be able to determine quickly if they need to run.

- Abstracting configuration data vs methods

Methods -> salt states; Configuration data -> grains/pillar. Grains are kind of attributes that belong to a host (like hostname, system version, installed packages, available ips, etc.), while pillar is a plugin system that can provide external data (it can be used like puppetdb too; I've got a plugin that pulls json files from s3 and talks makes it available as a simple hash for example). If you know chef, think attributes/databags (but better).

- PuppetDB as a canonical reference of the state of all our infrastructure.

It doesn't actually provide this out of the box, but provides the needed elements so this is trivial. Basically you can query all your nodes from the salt server (or nodes can query each other). You just need to extract the bits you need and save them to whatever destination you want. For example on the server run `salt -G 'roles:database' grains.item mem_total` and save the data. You can also define a "returner" which is a plugin that handles the data you get back and for example implement something that writes the data back into your information store/cmdb.

- Exported resources (also relying on PuppetDB), enabling propagation of information about new nodes to all others.

Pillar again. Although depending on what you want to achieve, you may want to enable some querying between the nodes, so that one of them can just broadcast some message at runtime and work on results.

But it also results in a mess of what-can-override-what. You can't have just #override. You've got "automatic", "default", "override" and later added "force_override" and "force_default", because "override"/"default" were not enough. And I'm still running into situations (especially when working with different teams deploying on the same host) where I want to override something that can't be changed anymore (or doesn't merge the way I need to).

This is one of the most annoying parts of chef for me. And it is quite complex: http://docs.opscode.com/essentials_cookbook_attribute_files....