4 ms·

I think the reason they didn't use a procedural language is because they specifically wanted to keep the playbooks declarative. Ideally, the playbook should de

I think the reason they didn't use a procedural language is because they specifically wanted to keep the playbooks declarative. Ideally, the playbook should describe the state you want the system to be in. This is 'almost' the case for most modules and I think this was a very good design decision. Having said that, the ghastly YAML format was almost a deal-breaker for me too.

davexunit 11y ago
Using a real programming language doesn't preclude a declarative programming style.
- moises_silva 11y ago
  No, but using a 'real' programming language doesn't force you to write in a declarative style unless you use something like a pure functional language and before you know it people would start making a mess in their playbooks using the whole power of Python. Ansible is awesome for devops precisely because it restricts what you can do and forces you to try to do things in a consistent declarative (and hence idempotent) style, which is important to devops. [edit: fix broken english]
  - lenkite 11y ago
    This could have been solved by choosing a language like lua and restricting the runtime environment - which is what is done in game software. Lua also has a tight, efficient interpreter. Making a mini-programming language in YAML is _coding horror_.
Florin_Andrei 11y ago
> the playbook should describe the state you want the system to be in This is the real reason. The playbook is the final state. How it gets there is of no interest to you. All you need to be concerned with is the final result - the state described by the playbook. All the extra complexity is handled by the software.
- davexunit 11y ago
  But you can declaratively specify a full system configuration in a real programming language, too. This is precisely what the GNU Guix system configuration API does, for example. You write OS configs in functional, declarative Scheme code. http://www.gnu.org/software/guix/manual/html_node/System-Configuration.html#System-Configuration http://www.gnu.org/software/guix/manual/html_node/System-Con...
themckman 11y ago
> ... keep playbooks declarative. I guess I've never really considered playbooks declarative. They are written like and feel like a script I'd write in a language like, I don't know, Python. Now, Salt state files I would consider declarative. They are simply Jinja templated dictionaries (Ansible is YAML that tries to find values templated with Jinja; BIG difference as I've discovered using Ansible for the last 6 months) that actually describe a set of states the host should be in. Ansible's playbooks encode a set of function calls that should be applied in a particular order. Don't get me wrong, playbooks ARE powerful in their ability to describe processes that span multiple hosts and I recognize that, but I'd really like to use a real programming language rather than some half-baked one that is encoded in YAML. I agree with the GP that I wish the Python API was a bit more robust. Currently we have several tools that generate playbooks on the fly, write them to temporary files and then run them with ansible-playbook to ensure we don't lose some functionality that makes playbooks as powerful as they are. Now, it appears the API has significantly changed in 2.0 and it looks like they expose (read: recommend using) more of it making it easier to script with Ansible.
quicksilver03 11y ago
Ansible's playbooks aren't declarative for me, I've came to the conclusion that they're a framework to write shell scripts. Dependencies are expressed by the sequence of the code blocks in the playbooks and roles, and I see them as implicit. In contrast, Puppet makes the dependency tree explicit with the "requires" language construct. The thing is, Ansible works well enough for 85% of the cases, where the additional complexity that Puppet brings is not needed.

davexunit 11y ago

Using a real programming language doesn't preclude a declarative programming style.

moises_silva 11y ago
No, but using a 'real' programming language doesn't force you to write in a declarative style unless you use something like a pure functional language and before you know it people would start making a mess in their playbooks using the whole power of Python. Ansible is awesome for devops precisely because it restricts what you can do and forces you to try to do things in a consistent declarative (and hence idempotent) style, which is important to devops. [edit: fix broken english]
- lenkite 11y ago
  This could have been solved by choosing a language like lua and restricting the runtime environment - which is what is done in game software. Lua also has a tight, efficient interpreter. Making a mini-programming language in YAML is _coding horror_.

Florin_Andrei 11y ago

> the playbook should describe the state you want the system to be in This is the real reason. The playbook is the final state. How it gets there is of no interest to you. All you need to be concerned with is the final result - the state described by the playbook. All the extra complexity is handled by the software.

davexunit 11y ago
But you can declaratively specify a full system configuration in a real programming language, too. This is precisely what the GNU Guix system configuration API does, for example. You write OS configs in functional, declarative Scheme code. http://www.gnu.org/software/guix/manual/html_node/System-Configuration.html#System-Configuration http://www.gnu.org/software/guix/manual/html_node/System-Con...

themckman 11y ago

> ... keep playbooks declarative. I guess I've never really considered playbooks declarative. They are written like and feel like a script I'd write in a language like, I don't know, Python. Now, Salt state files I would consider declarative. They are simply Jinja templated dictionaries (Ansible is YAML that tries to find values templated with Jinja; BIG difference as I've discovered using Ansible for the last 6 months) that actually describe a set of states the host should be in. Ansible's playbooks encode a set of function calls that should be applied in a particular order. Don't get me wrong, playbooks ARE powerful in their ability to describe processes that span multiple hosts and I recognize that, but I'd really like to use a real programming language rather than some half-baked one that is encoded in YAML. I agree with the GP that I wish the Python API was a bit more robust. Currently we have several tools that generate playbooks on the fly, write them to temporary files and then run them with ansible-playbook to ensure we don't lose some functionality that makes playbooks as powerful as they are. Now, it appears the API has significantly changed in 2.0 and it looks like they expose (read: recommend using) more of it making it easier to script with Ansible.

quicksilver03 11y ago

Ansible's playbooks aren't declarative for me, I've came to the conclusion that they're a framework to write shell scripts. Dependencies are expressed by the sequence of the code blocks in the playbooks and roles, and I see them as implicit. In contrast, Puppet makes the dependency tree explicit with the "requires" language construct. The thing is, Ansible works well enough for 85% of the cases, where the additional complexity that Puppet brings is not needed.