Hacker News Reader

Comment by ymse | Hacker News Reader

Which design flaws are you referring to? As a recent Salt convert (and Puppet expert), I was perplexed as to why such a nice tool would have a man page 40x longer than bash.

Turns out it includes extensive documentation for all states supported by Salt, generated from the online documentation. Compare this to the Puppet manual:

    $ man puppet
    PUPPET(8)                Puppet manual                         PUPPET(8)

    NAME
       puppet

       See ´puppet help´ for help on available puppet subcommands

Obviously no-one will be using everything that Salt supports, so it would be nice if it was broken into sub-sections. But I much prefer having all documentation available in a manual to looping through every module and run "rdoc" as in the Puppet case.

Any sufficiently popular configuration management tool will have equally long documentation.

There are a couple of simpler options available:

http://www.nico.schottelius.org/software/cdist/

https://github.com/brandonhilkert/fucking_shell_scripts

View on HN

"Design flaw" might not be right description. Maybe, "Naive implementations with nearly useless documentation" is better.

When I first started using puppet, I would go home absolutely exhausted every night. Their design choices, along with a lack of documentation, would turn the equivalent of a 20 minute bash script into something that would take days. Best example I can think of is the arbitrary ordering of module execution. I understand why they do it this way, but if they documented it in plain sight, then maybe my desk wouldn't have a forehead shaped dent in it. Similar goes for the other tools.

The only thing I can think of that prevents companies from releasing proper documentation is because of their expensive support contracts. There's a lot of incentive to make a standard incredibly difficult.

I just want accessible tools :(

edit: fss looks pretty neat! Kinda rpm-y, but it fits a nice middle ground.

I get your sentiment. I only started using Salt some months ago, but it was really a breath of fresh air compared to Puppet. However it took me a while to realize its true strengths since the documentation is very...dry.

IIRC Ansible, like Chef, does serial execution. That is, states are applied in the order they are written. I think that's part of the reason it has gotten so popular, as you'll have very few surprises in the vein of "what do you mean there is no ntp_service -- it's right there next to the config declaration!".

What Salt got right is the pillar, for which the Puppet equivalent (Hiera) was an afterthought. The Salt engine allows you to generate states from the pillar, rather than making poor clones of Puppet modules (as most of the formulas I've seen online).

However that flexibility is not documented anywhere, nor part of best practices. Nevertheless I'm about to release a set of formulas that are truly pillar-driven with no hard-coded stuff. Keep an eye out for the accompanying blog post :)

Of course, if you don't care about data/code separation and just want to get stuff done, there are better tools. And if you have full control of your environment, I would strongly suggest using Guix and/or Nix rather than these legacy configuration management tools.

I actually really like salt, just not its documentation. Like you said - it was a breath of fresh air. :)

Last time I used it a few months ago, it was while helping out another admin. He had a lot of confusion on how to do certain things, and the documentation wasn't very helpful for either of us. The solution came from github, which has become my go-to for these sorts of tools. Though, that could easily be supplemented with some better examples on their site, or in their, erm, man page.

I doubt we'll have some great tools with great documentation anytime soon (or monitoring tools!), but a sysadmin can dream... :)

Reply on news.ycombinator.com