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