Hacker News Reader

Comment by gerbilly | Hacker News Reader

I think we have to distinguish two things going on in Ansible files.

1) It's declarative. So if you are looking for a procedural language, you will be disappointed. It's also declarative for good reason IMHO.

2) It's still hacky. If the 'language' remained entirely declarative then the YAML syntax _might_ have been ok, but the language looks like a poor design stretched beyond it's limits.

Some people don't like the Ansible language for reason 1 or some for reason 2.

Personally, I prefer that it's declarative, the file is supposed to describe the features the target system must have, and then the module, which is procedural, has to figure out how to make that happen on whatever target system is in question.

That separation keeps things clean, idempotent (most times) and neat.

I think procedural approaches _seem_ better because they are familiar to programmers, but they can become complex, non-idempotent and hard to debug.

View on HN

I've used Ansible quite a bit, and I could sometimes sum it up as, "the worst one, except for its alternatives".

I tend to think of Ansible as supporting a flexible combination of declarative and procedural approaches. Within a particular sequence of tasks, it's procedural. Those lists of tasks are typically combined into a role or the like that is typically more declarative in its application. Of course application of roles is actually procedural in that it happens in the same obvious order it's defined, but the higher level organizational constructs like roles have more of a declarative feel to me (I'd assume that's by design).

Ansible has none of the things that make declarative languages good, though. Good Declarative languages allow composition - Having a base object, adding properties to it, overriding others. Ansible handles none of that in it's playbook syntax or it's vars syntax. In the role and module syntax, sure, but they're turing complete anyway.

I agree that it's crufty.

If I were them I'd sunset the old syntax in the next version, create a conversion tool that works for 90% of cases and then drop support for the old file format.

But that's what I would do, and it would probably kill the project.

As soon as people can't cut and paste Ansible 1.x roles from github into their project, Ansible would probably start to wither.[1]

That's the typical workflow. You need to do something on your linux box. You google that, find a decent Ansible solution, cut and paste a few text files maybe modify it a bit and repeat.

[1] And this s another reason declarative syntax is so awesome, because it's easy to snap roles together like lego bricks.

Every time I let the config management stuff slide slowly towards procedural, bad things have happened.

You want your config management templates to be as declarative as possible. "This is the desired final state", and that's it. Of course, in practice it's very hard to stay 100% declarative, but it's very good practice to try and keep it close to ideal.

Agreed, this is a great way to think about it. I think Ansible is at its best when the modules handle the imperative stuff behind the scenes, and the playbook just declares. That's not always possible, but the modules are getting better and better.

FWIW I also found YAML to be very confusing syntactically at first; things got easier once I realized that it's basically 1-to-1 with JSON, and could convert to JSON to get intuition for the file structure (simple yaml2json script here: http://pastebin.com/TpjZLnLa). Thumbing through the book Ansible Up and Running also helped.

In the long run, putting a declarative idempotent layer atop the same old mutable infra is tough but a necessary compromise right now. It'll be great if the immutable-first tools of today (nixos et al) mature and we can leave this behind.

Reply on news.ycombinator.com