[karlicoss]

Yes.

- you use an actual programming language (which you're likely to already know) instead of desperately figuring out how to simulate a for loop in yaml or to replace a part of a string, or whatnot

- you have all Python static analysis tools at your disposal. mypy/pylint etc can make your deploys less error prone

- you can easily implement a custom DSL in python, so deploys ends up more declarative and with less copy pasting

- it's easy to implement custom arbitrary operations (since you're working in python) -- and again you can reuse variables, etc instead of having to use some weird templating or pass them in command line

[usrme]

At what point are you just re-inventing what Ansible already does if you're going down the DSL path? I sometimes feel like I'm in the minority, but I truly do like Ansible and if you slap Mitogen[1] in front of it makes the whole process even more enjoyable!

I'm honestly trying to understand whether this hating on Ansible is more of a bandwagon thing (similar to how people shit on the Python dependency management ecosystem) and stems from having bad experiences that have completely turned them off of it.

Honest questions in response to your points:

1. What are you deploying where you would need static analysis?

2. If you did end up writing your own DSL on top of Python at what point would you concede that it's probably better to use someone's else creation as opposed to forever iterating on your own thing for the sake of using your own thing?

3. Why would you want "custom arbitrary operations" and how custom are they that Ansible and Jinja2 can't do that for you in usage patterns that are far more common than your own creation would be?

---

[1]: https://mitogen.networkgenomics.com/ansible_detailed.html

[traverseda]

One example where I personally ran into trouble with ansible was in dealing with SSL certificates. In production we use letsencrypt to generate SSL certificates as you'd expect, but for testing we were using self-signed certificates. This was surprisingly complicated under the ansible model, basically I ended up writing a reusable playbook that worked more or less as a function, and running a hook at the end to actually create the keys. Due to the specifics of our app depending on what kind you needed the actual certificate paths got the certificates were different.

So I ended up doing some crazy hacks passing around state instead of just writing a function.

[Terretta]

Feels as though perhaps this should have dropped from playbook into a module?

https://docs.ansible.com/ansible/latest/dev_guide/developing...

Then just writing a function.

[senorsmile]

It should have at least become a role that could be called in the different contexts of the environment it was targetting. Ansible's real power is in the hierarchical inventory, which can be used to efficiently describe the state of all of the things (I use it for everything from cloud things to specific machine things).

[traverseda]

Sure, but there's something to be said for locality of behavior.

[mdeeks]

Does mitogen really only support up to Ansible 2.9? Thats a couple years old isn't it? I was really excited for it until I saw that :(

[usrme]

I'm on 'ansible==5.5.0' / 'ansible-core==2.12.3' and am using Mitogen with no issues whatsoever.

[PaywallBuster]

Have releases up to 2.13

https://github.com/willhallonline/docker-ansible

Still multiple major releases behind but still

Also I wonder how often the new releases are used (market share?) since so many people moved to cloud/k8s

[_ktx2]

> At what point are you just re-inventing what Ansible already does if you're going down the DSL path

For one, YAML can only emulate one kind of DSL: a declarative language. You have no advanced operations on top of YAML without using modern YAMLv3 syntax which is honestly mind boggling to read at times. Python is far more expressive and has tooling that can strengthen your operational resilience.

> I'm honestly trying to understand whether this hating on Ansible is more of a bandwagon thing

I've heard this expression echoed commonly when ones favorite tooling is under critique. Nobody hates Ansible, people do have experience that's taught them not to use something. Whether you feel your case overlaps with theirs is an exercise that pithy internet opinions can't sort out for you.

> What are you deploying where you would need static analysis?

Anything sufficiently dynamic. Static analysis is for making things less error prone. There's still all the same runtime problems, but at least there's an expressive path to fixing the runtime problems.

> 2. If you did end up writing your own DSL on top of Python at what point would you concede that it's probably better to use someone's else creation as opposed to forever iterating on your own thing for the sake of using your own thing?

That's a value judgement as to whether the person you're speaking to feels comfortable writing and maintaining a DSL. In my own experience, I've written things on my own that I had full control over that were sufficiently narrowly defined and I was able to move fast because of those things. I've also sat around waiting for features I'll never get or waiting for someone else's use case to become mine without avail because someone refused to "reinvent the wheel" without realizing the wheel they think exists isn't real.

> Why would you want "custom arbitrary operations" and how custom are they that Ansible and Jinja2 can't do that for you in usage patterns that are far more common than your own creation would be?

The custom orchestrators I've written were compensating for software that is deeply entrenched in it's infra and vice versa. Jinja buys me nothing that writing in Python or Go can, and Ansible is providing facilities the languages already give me. Ansible, in this case, is very much there to serve Jinja.

Of course, that's not to say that either way is wrong. Sometimes it's appropriate to use Ansible. Other times it's appropriate to write your own. Even in the latter decision, by doing so, it affords learnings about what you'll need beneath the hood so you can make educated decisions if you roll back to the former.

[blondin]

so pulumi[1]?

[1]: https://github.com/pulumi/pulumi

[latchkey]

As much as I want to love pulumi, their ssh story seems missing. It feels like pulumi is dedicated towards managing cloud instances through cloud apis, while I'd want to manage bare metal instances through ssh (or a local daemon). I'd love correction on this.

[pbecotte]

no, you're right. Terraform/Pulumi are much more focused on provisioning resources, while Ansible has its sweet spot in configuring a machine once its running.