4 ms·

I really wish Ansible would have chosen to use python instead of YAML (since that's what it ends up being anyways). Shoehorning actual programming logic into YA

I really wish Ansible would have chosen to use python instead of YAML (since that's what it ends up being anyways). Shoehorning actual programming logic into YAML files is just awful; Working with Ansible as a software engineer is without a doubt the worst work I've done in my professional career. Every otherwise simple logic structure in any programming language like loops, variable declaration, or conditional statements take 5x as much space and are very difficult to understand immediately. My first love in this space was Chef, and honestly it remains my favorite in config management because you can write things in it that look very non-programmy, but you're still just writing in pure ruby. Obviously Ansible has the advantage being agentless, but I just cannot stand how popular it is.

SteveNuts 3y ago
Ansible is a nice tradeoff to allow sysadmins with no programming experience to work with it, and someday hopefully graduate to something else. For that, I think it's a net-positive. But yes, trying to work with even mildly complex data structures in Ansible is a nightmare compared to raw Python.
zufallsheld 3y ago
As a counter anecdote I can tell you that all of the ops-people I worked with, they gladly switched from Puppet and Chef to Ansible, specifically because it was less programming and more shell-like. Not that this is good or bad, but I think that's why Ansible took off with the traditional operations-teams.
- jauntywundrkind 3y ago
  More shell like, and more normative. There's a given form & shape in Ansible; playbooks resemble each other. You don't get that with programming languages. People do all kinds of shit with programming languages. There's tons of good ways to tackle a problem. And exponentially many more bad ways to tackle a problem. Having a given repeated form makes interpreting & understanding Ansible far easier than the alternatives.
syslog 3y ago
If you try to use a hammer like a screwdriver, you’re going to be frustrated.
- deleted 3y ago
  [deleted]
mikeocool 3y ago
When I was first using chef -- and didn't quite get the paradigm -- it was really easy to fallback to a lot of native ruby. i.e. "I dont want to run these resources in certain contexts, let me just wrap them in an if statement." Which ended up creating a bit of a mess over time, and broke some of chef's functionality. By using yaml ansible basically forces you to be purely declarative, which I found to be a boon, especially once other engineers who similarly didn't initially get the declarative paradigm started on working in the codebase.
xorcist 3y ago
I see you haven't worked with Istio, yet. Kidding aside, it is somewhat amusing to see the same discussion as when chef happened repeat itself. Ansible clearly had to take a lot of liberties with the yaml format to make it work in practice. The amount of yaml in yaml you have to write is surprising. I cannot wait for the cycle to repeat itself.
- mdaniel 3y ago
  > Ansible clearly had to take a lot of liberties with the yaml format to make it work in practice and yet, completely facepalmed by invoking Jinja2 with its default begin and end characters that are meaningful to yaml, thus ensuring billions of person-years of SO questions due to having to quote, sometimes multiple ways, every jinja2 invocation Contrast that to GitHub Actions which uses ${{ }} for its parameterization and thus no quoting required, in contrast to - debug: msg: '{{ "what kind of lack of forethought was this nonsense" }}'
dig1 3y ago
I think this is more a personal preference rather than something practical. As a counter-example, I've implemented Ansible-like syntax as a configuration for a couple of unrelated projects, and people like it because it is similar to Ansible, which is used for infrastructure management. I doubt I'd do that by writing a parser for Python-like configuration language. Also, don't forget that yaml is way easier to pick up by non-python developers and people unfamiliar with programming.
bityard 3y ago
Haven't used it in anger yet, but I have high hopes for PyInfra: https://github.com/pyinfra-dev/pyinfra https://github.com/pyinfra-dev/pyinfra

SteveNuts 3y ago

Ansible is a nice tradeoff to allow sysadmins with no programming experience to work with it, and someday hopefully graduate to something else. For that, I think it's a net-positive. But yes, trying to work with even mildly complex data structures in Ansible is a nightmare compared to raw Python.

zufallsheld 3y ago

As a counter anecdote I can tell you that all of the ops-people I worked with, they gladly switched from Puppet and Chef to Ansible, specifically because it was less programming and more shell-like. Not that this is good or bad, but I think that's why Ansible took off with the traditional operations-teams.

jauntywundrkind 3y ago
More shell like, and more normative. There's a given form & shape in Ansible; playbooks resemble each other. You don't get that with programming languages. People do all kinds of shit with programming languages. There's tons of good ways to tackle a problem. And exponentially many more bad ways to tackle a problem. Having a given repeated form makes interpreting & understanding Ansible far easier than the alternatives.

syslog 3y ago

If you try to use a hammer like a screwdriver, you’re going to be frustrated.

deleted 3y ago
[deleted]

mikeocool 3y ago

When I was first using chef -- and didn't quite get the paradigm -- it was really easy to fallback to a lot of native ruby. i.e. "I dont want to run these resources in certain contexts, let me just wrap them in an if statement." Which ended up creating a bit of a mess over time, and broke some of chef's functionality. By using yaml ansible basically forces you to be purely declarative, which I found to be a boon, especially once other engineers who similarly didn't initially get the declarative paradigm started on working in the codebase.

xorcist 3y ago

I see you haven't worked with Istio, yet. Kidding aside, it is somewhat amusing to see the same discussion as when chef happened repeat itself. Ansible clearly had to take a lot of liberties with the yaml format to make it work in practice. The amount of yaml in yaml you have to write is surprising. I cannot wait for the cycle to repeat itself.

mdaniel 3y ago
> Ansible clearly had to take a lot of liberties with the yaml format to make it work in practice and yet, completely facepalmed by invoking Jinja2 with its default begin and end characters that are meaningful to yaml, thus ensuring billions of person-years of SO questions due to having to quote, sometimes multiple ways, every jinja2 invocation Contrast that to GitHub Actions which uses ${{ }} for its parameterization and thus no quoting required, in contrast to - debug: msg: '{{ "what kind of lack of forethought was this nonsense" }}'

dig1 3y ago

I think this is more a personal preference rather than something practical. As a counter-example, I've implemented Ansible-like syntax as a configuration for a couple of unrelated projects, and people like it because it is similar to Ansible, which is used for infrastructure management. I doubt I'd do that by writing a parser for Python-like configuration language. Also, don't forget that yaml is way easier to pick up by non-python developers and people unfamiliar with programming.

bityard 3y ago

Haven't used it in anger yet, but I have high hopes for PyInfra: https://github.com/pyinfra-dev/pyinfra https://github.com/pyinfra-dev/pyinfra