3 ms·

>any mature syntax tree parsers should be able to do it. Well thats' just it, I don't think they use such a parser. I always thought that's why they use YAML

>any mature syntax tree parsers should be able to do it. Well thats' just it, I don't think they use such a parser. I always thought that's why they use YAML as their input language, to avoid having to write a parser, I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design. [1] https://www.freebsd.org/cgi/man.cgi?query=termcap&sektion=5 https://www.freebsd.org/cgi/man.cgi?query=termcap&sektion=5 (Also known in my day as 'turdcap'.)

threatofrain 10y ago
I speculate that Ansible choose YAML under the premise that it would lower the barrier to entry as opposed to a real language like Python or whatever. That would be nice if everything were just a matter of configurations, in which case YAML would be just as good as JSON, if not better. The problem is that because people want logic, Ansible ended up introducing an idiosyncratic YAML-templating language that's not actually YAML or anything else. Now people write large system deployment scripts in this weird YAML that I don't ever want to look at.
- collyw 10y ago
  JSON is crap for configuration. Its picky with quotes, doesn't like trailing commas, and isn't as readable as other options.
  - threatofrain 10y ago
    JSON is the example, not the prescription; JSON is just a widely used format for arbitrarily nested data. You can use Javascript objects (or Python dictionaries) if you want. Again, this example applies for the scenario if Ansible playbooks were only configurations. If it were only configurations, then fine, let's go with readable YAML. If Ansible were playbooks with only configurations, then even XML would be okay, because in the sum of all pros and cons, this would be a tiny factor. The pickiness of quotes and trailing commas is really whatever here. But instead Ansible playbooks use a "readable" YAML-ish language. The price is not right.
willejs 10y ago
RE: "I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design." I've been a puppet user, and long time chef user, and recently been using ansible for a couple of projects, but I can't learn to like the 'language' at all. I feel like ansibles YAML syntax is just hiding the complexity of configuration management from you. Which at first as a novice ansible and CM user, or for small projects is great! You can be super productive, and anyone can understand it in your team. However, as your systems get more complex, I feel like doing anything remotely complex with it produces confusing, hacky, unreadable ansible 'code'. Then you try to scale this working in a team, and try to do any useful testing, or re-use/extend/share any roles, your kind of doomed. The reason I continue to use chef is because its a ruby DSL that you can easily extend, where anyone who can code; can write, test and understand. While I find Ansible is just templated YAML, and means you dont have to understand how to program. I guess my point is, configuration management is kind of hard. I feel like people use Ansible because 'its easy', and I hear people say 'Ansible is easy' a lot. But in the end, Ansible, the tool chain, workflows and syntax will become just as complex as chef/puppet/saltstack when you operate it at scale.
- gerbilly 10y ago
  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.
  - phunge 10y ago
    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 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.

threatofrain 10y ago

I speculate that Ansible choose YAML under the premise that it would lower the barrier to entry as opposed to a real language like Python or whatever. That would be nice if everything were just a matter of configurations, in which case YAML would be just as good as JSON, if not better. The problem is that because people want logic, Ansible ended up introducing an idiosyncratic YAML-templating language that's not actually YAML or anything else. Now people write large system deployment scripts in this weird YAML that I don't ever want to look at.

collyw 10y ago
JSON is crap for configuration. Its picky with quotes, doesn't like trailing commas, and isn't as readable as other options.
- threatofrain 10y ago
  JSON is the example, not the prescription; JSON is just a widely used format for arbitrarily nested data. You can use Javascript objects (or Python dictionaries) if you want. Again, this example applies for the scenario if Ansible playbooks were only configurations. If it were only configurations, then fine, let's go with readable YAML. If Ansible were playbooks with only configurations, then even XML would be okay, because in the sum of all pros and cons, this would be a tiny factor. The pickiness of quotes and trailing commas is really whatever here. But instead Ansible playbooks use a "readable" YAML-ish language. The price is not right.

willejs 10y ago

RE: "I like many things about Ansible, but the 'language' is an unreadable mess that makes termcap[1] feel like genius level UX design." I've been a puppet user, and long time chef user, and recently been using ansible for a couple of projects, but I can't learn to like the 'language' at all. I feel like ansibles YAML syntax is just hiding the complexity of configuration management from you. Which at first as a novice ansible and CM user, or for small projects is great! You can be super productive, and anyone can understand it in your team. However, as your systems get more complex, I feel like doing anything remotely complex with it produces confusing, hacky, unreadable ansible 'code'. Then you try to scale this working in a team, and try to do any useful testing, or re-use/extend/share any roles, your kind of doomed. The reason I continue to use chef is because its a ruby DSL that you can easily extend, where anyone who can code; can write, test and understand. While I find Ansible is just templated YAML, and means you dont have to understand how to program. I guess my point is, configuration management is kind of hard. I feel like people use Ansible because 'its easy', and I hear people say 'Ansible is easy' a lot. But in the end, Ansible, the tool chain, workflows and syntax will become just as complex as chef/puppet/saltstack when you operate it at scale.

gerbilly 10y ago
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.
- phunge 10y ago
  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 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.