Hacker News Reader

Comment by lobster_johnson | Hacker News Reader

I've used Puppet, Ansible and Salt. While they get the job done, they all suck in a myriad of ways. They're slow, brittle, have bad documentation (I'm probably being cynical, but Puppet, Ansible and Salt all seem to have been created as consulting companies first and software second; they thrive on the inadequacy of their documentation).

One problem with the "post-Puppet/Chef" generation of tools is the over-reliance of templatized YAML as a DSL. Salt's use of YAML is particularly egregrious. For all the criticisms of Puppet's custom language, at least it's a language, with proper types, a consistent syntax, and a good measure of strictness. I like YAML as configuration file language, but it's terrible for DSLs.

View on HN

I agree with you (esp. on YAML being a poor base for DSLs), but I've found that Chef has the best documentation out of all of these tools. I used to recommend Ansible as the CM tool of choice but lately I've been digging Chef. Installing agents isn't ideal, but managing control servers isn't a panacea either and Chef can run in solo mode just fine. Additionally, if you use Packer or Terraform/Cobbler/RackHD for managing buildouts, installing and staging Chef isn't that hard; it's actually quite trivial

Without being a comparison the other tool(s), I would make a point regarding to your blocker, which actually it shouldn't be a blocker.

Many folks miss one important point: Salt's renderer interface is also pluggable. There are quite a few choices for you: https://docs.saltstack.com/en/latest/ref/renderers/index.htm.... For data representation you can choose between: yaml, yamlex, json, json5, hjson, or even pure python. Nothing else can be more flexible than pure python. But, of course, this approach also has its drawbacks. Anyway, if none of them suits your needs for non-terrible DSL, you can even implement your own DSL, your own renderer.

All you have to do is adding few characters at the top of your pillar, i.e. #!json or #!json5 or even #!lobster.

So where is the limitation again? In reading documentation I guess.

The Python interface is the only one that addresses my criticisms, but do people actually use it? Is it well supported, stable and so on?

The YAML is the default, and it's what you find examples and support for (Stack Overflow and so on). I get the impression that many of the renderers are not "official", in the sense that they're maintained by other people.

If Salt only provided a Python API, the situation would be different. As such, it's a case of too much choice, and not enough standardization. There are no less than three competing Python renderers.

I'm not entirely sure I understand you. Do you find it bad that there are several options?

I had the feeling that YAML is the one that addresses your criticism ("I like YAML as configuration file language, but it's terrible for DSLs."). And yes, I do use the python one and I am very happy with it.

> The YAML is the default, and it's what you find examples and support for (Stack Overflow and so on)

Pro tip: if they are YAML on StackOverflow, you don't have to copy-paste them, but more rather translate them to the representation that satisfy your high requirements.

It's a common misconception to read too much into Renderers. Salt's State system takes a data structure as input so each of the Renderer modules is really just what flavor of "data structure generator" you like most.

The so-called highstate data structure is very stable and well documented so Renders rarely need changes:

https://docs.saltstack.com/en/latest/ref/states/highstate.ht...

The regular Python interface you mentioned is my favorite too, when YAML/Jinja aren't a good fit, and people do use it. It's 40 LOC and has only needed 32 commits in the six years it's been around:

https://github.com/saltstack/salt/blob/5406a7cdd4729/salt/re...

The takeaway is YAML/Jinja generate exactly the same result as the Python Renderer so use what you like.

I'm surprised to see this particular criticism applied across the board – Puppet's documentation is one of my favorite things about it.

Admittedly, Puppet's documentation is better than it used to be; I've been using it since 1.x, and it used to be a lot worse. However, it's still a bit tedious to browse through.

The weakest part has always finding reference documentation — that is, things like this [1]. Everything is a bit buried and scattered. At least they finally have a complete list of configuration settings [2] now, which used to be a huge pain.

[1] https://docs.puppet.com/puppet/4.10/types/file.html

[2] https://docs.puppet.com/puppet/4.10/configuration.html

The current version of the Puppet documentation all appears to be for the enterprise product. Our team just evaluated the three and easily found Puppet to have the worst documentation for starting out with the free edition.

Reply on news.ycombinator.com