4 ms·

Ansible has worked really well for us at Pathwright. We initially played a lot with Chef and Puppet, as they're two really safe bets. This is kind of petty, but

by gtaylor 13y ago

Ansible has worked really well for us at Pathwright. We initially played a lot with Chef and Puppet, as they're two really safe bets. This is kind of petty, but we're a Python shop, so the Rubyisms were a bit jarring. Both were also a bit harder to pick up while short on time. This new thing (at the time) called Ansible caught our eye, and it only took a few days to see that it was a great fit for us. While Ansible is developed in Python, it doesn't leak through to the UI and the playbooks. It's all just YAML. Learn a little Jinja2, grok the directory structure, and you're set. The playbook format is simple, and even people without any Ansible experience can pick through and get a basic idea of what's going on. Pythonistas, Rubyists, whatever. It's just YAML. My only criticism is that the documentation isn't organized very well just yet. This is common with projects that are rapidly growing/improving, and I expect it to get better. In particular, I think the doc index needs to be trimmed a LOT, with more content being delegated to sub-sections: http://www.ansibleworks.com/docs/ http://www.ansibleworks.com/docs/ Overall, great utility, very helpful community, loads of potential.

ams6110 13y ago
I'm not a fan of yaml but I do love Ansible anyway. Another nice thing about it is that it requires nothing on the remote side other than a running sshd and stock python. You don't need to deploy anything like a chef client to each remote system.
- gtaylor 13y ago
  True on all accounts. I'm not a YAML fan either, but it ends up being a pretty minor detail for us. It is very convenient not having to run an agent on the managed machines.
  - rytis 13y ago
    Just out of curiosity, what's the problem with YAML?
    - lutusp 13y ago
      The problem with YAML is its reliance on syntactically significant whitespace, a trait that makes the result not seriously human-readable or editable. Once you can't reliably read or edit the source, you lose the original reason to use plain text -- binary representations tend to be smaller, after you've given up on the idea of hand-editing or interepreting by eye. This, by the way, is a defect shared by Python source code, one of the few drawbacks to a very productive language. In Python, if a single space gets removed from a source file, the consequences can be severe and difficult to either detect or correct.
      - rlpb 13y ago
        You have, I think, quite a controversial opinion. The other side of this is that in syntaxes which have some other hierarchical delimiter (such as curly braces), it is quite a common mistake for a human to see one thing, and for the computer to interpret another. In such a syntax, if a single semicolon or curly brace is missing or misplaced, the consequences can be severe and difficult to either detect or correct. At least with whitespace, what you see is what the computer also sees.
        lutusp 13y ago
        > The other side of this is that in syntaxes which have some other hierarchical delimiter (such as curly braces), it is quite a common mistake for a human to see one thing, and for the computer to interpret another. Yes, but in the case of explicit delimiters, the situation can be resolved fully and automatically by counting delimiters -- either there are an equal number of delimiters (i.e. N('{') - N('}') == 0) or there aren't. The computer can be relied on to discover this simple relationship and raise an alarm, one that puts the error before the programmer in unambiguous form. By contrast, in Python, in many cases the program compiles, runs, and produces a different result than if the error were not present. The program is syntactically correct in both forms, but its meaning has changed. In the Python case, the program may have a different meaning, and produce a different result, than the human intended without an alarm being raised. > At least with whitespace, what you see is what the computer also sees. Depending on what you mean by "see", not necessarily so. The programmer may intend something that that program, as written, cannot produce, because of an ambiguity related to the lack of formal delimiters, an ambiguity that causes the computer to understand the program differently than the human, and produce results that the human didn't intend. All this apart from the nightmare produced by mixing tabs and spaces in the same source file. This may seem an unrelated issue at first glance, but mixing tabs and spaces in a language that uses explicit delimiters is just bad practice, but in Python (and in YAML) it can be a very serious problem. It's why Google's published syntax guidelines forbid use of tabs. When tabs are used, two standard tabs produce a 16-character-space indentation and two syntactic indentations. When spaces are used, two spaces produce two character-space indentations and one syntactic indentation (by Google's standards, i.e. two-space indentations). Unless the programmer is using an editor that prevents insertion of tabs into the source, this is an accident waiting to happen -- but only in the case that whitespace is syntactically significant. Further (entertaining) reading: https://www.google.com/search?q=python+indentation+error https://www.google.com/search?q=python+indentation+error
mblakele 13y ago
Ansible is probably the best configuration management tool out there. But there is always room for improvement. Better docs would be great. I would like to see jinja2 templates replaced with something much, much better. And there is still more work to do for cloud applications.
ermintrude 13y ago
Personally I think the ansible docs are very good. If you think they're bad, try looking at the salt docs which are absolutely rubbish.
- gtaylor 13y ago
  I definitely don't think that they are bad, just not great. It's not even really a lack of content like with the Salt docs, it's more of an organization issue.

by gtaylor 13y ago

ams6110 13y ago

I'm not a fan of yaml but I do love Ansible anyway. Another nice thing about it is that it requires nothing on the remote side other than a running sshd and stock python. You don't need to deploy anything like a chef client to each remote system.

gtaylor 13y ago
True on all accounts. I'm not a YAML fan either, but it ends up being a pretty minor detail for us. It is very convenient not having to run an agent on the managed machines.
- rytis 13y ago
  Just out of curiosity, what's the problem with YAML?
  - lutusp 13y ago
    The problem with YAML is its reliance on syntactically significant whitespace, a trait that makes the result not seriously human-readable or editable. Once you can't reliably read or edit the source, you lose the original reason to use plain text -- binary representations tend to be smaller, after you've given up on the idea of hand-editing or interepreting by eye. This, by the way, is a defect shared by Python source code, one of the few drawbacks to a very productive language. In Python, if a single space gets removed from a source file, the consequences can be severe and difficult to either detect or correct.
    - rlpb 13y ago
      You have, I think, quite a controversial opinion. The other side of this is that in syntaxes which have some other hierarchical delimiter (such as curly braces), it is quite a common mistake for a human to see one thing, and for the computer to interpret another. In such a syntax, if a single semicolon or curly brace is missing or misplaced, the consequences can be severe and difficult to either detect or correct. At least with whitespace, what you see is what the computer also sees.
      - lutusp 13y ago
        > The other side of this is that in syntaxes which have some other hierarchical delimiter (such as curly braces), it is quite a common mistake for a human to see one thing, and for the computer to interpret another. Yes, but in the case of explicit delimiters, the situation can be resolved fully and automatically by counting delimiters -- either there are an equal number of delimiters (i.e. N('{') - N('}') == 0) or there aren't. The computer can be relied on to discover this simple relationship and raise an alarm, one that puts the error before the programmer in unambiguous form. By contrast, in Python, in many cases the program compiles, runs, and produces a different result than if the error were not present. The program is syntactically correct in both forms, but its meaning has changed. In the Python case, the program may have a different meaning, and produce a different result, than the human intended without an alarm being raised. > At least with whitespace, what you see is what the computer also sees. Depending on what you mean by "see", not necessarily so. The programmer may intend something that that program, as written, cannot produce, because of an ambiguity related to the lack of formal delimiters, an ambiguity that causes the computer to understand the program differently than the human, and produce results that the human didn't intend. All this apart from the nightmare produced by mixing tabs and spaces in the same source file. This may seem an unrelated issue at first glance, but mixing tabs and spaces in a language that uses explicit delimiters is just bad practice, but in Python (and in YAML) it can be a very serious problem. It's why Google's published syntax guidelines forbid use of tabs. When tabs are used, two standard tabs produce a 16-character-space indentation and two syntactic indentations. When spaces are used, two spaces produce two character-space indentations and one syntactic indentation (by Google's standards, i.e. two-space indentations). Unless the programmer is using an editor that prevents insertion of tabs into the source, this is an accident waiting to happen -- but only in the case that whitespace is syntactically significant. Further (entertaining) reading: https://www.google.com/search?q=python+indentation+error https://www.google.com/search?q=python+indentation+error

mblakele 13y ago

Ansible is probably the best configuration management tool out there. But there is always room for improvement. Better docs would be great. I would like to see jinja2 templates replaced with something much, much better. And there is still more work to do for cloud applications.

ermintrude 13y ago

Personally I think the ansible docs are very good. If you think they're bad, try looking at the salt docs which are absolutely rubbish.

gtaylor 13y ago
I definitely don't think that they are bad, just not great. It's not even really a lack of content like with the Salt docs, it's more of an organization issue.