Pyinfra automates infrastructure super fast at scale

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.

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 :(

> 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.

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.