3 ms·

Cool. Ansible is still going to be around for some time. Also reminds me again that yaml should have never been born. Look how unnatural this "language" is in

by kunley 3y ago

Cool. Ansible is still going to be around for some time. Also reminds me again that yaml should have never been born. Look how unnatural this "language" is in this article's examples

xienze 3y ago
Most of that is the embedded templating/scripting system (the stuff between {{}}), not YAML itself.
- zufallsheld 3y ago
  Well, that's Jinja. And arguably not a bad tool, but not the best for the use-case of config-management.
  - kunley 3y ago
    Yeah, I just have this sentiment wishing that Ansible's author used own-crafted format. HashiCorp used their own and suddenly in this case no one says "yaml should be everywhere because it's everywhere already". In a similar mood, I wished Kubernetes was staying every from yaml. Even mentioned HCL would be better (although it's not perfect)
- kunley 3y ago
  Yes but the task names and parameters try to mimic natural language, like assert: that:, so you're supposed to read it as a whole, and it quickly turns into an abomination, with one syntax (yaml) for the structure and another (jinja) for values and conditions
avgcorrection 3y ago
Yeah. I don’t understand why we keep submitting ourselves to this way of working.
linsomniac 3y ago
IMHO, the issue is that Ansible uses YAML to do "programming language" sorts of things, which is why it feels so unnatural. I tried an experiment last year: What if Ansible had Python rather than YAML syntax. https://github.com/linsomniac/uplaybook?tab=readme-ov-file#simple-examples https://github.com/linsomniac/uplaybook?tab=readme-ov-file#s... The downside is that having full Python available makes it really easy to make your playbooks non-idempotent, which Ansible gate-keeps behind Ansible modules. Also someone raised a concern that full Python (rather than a more limited safe dialect like Starlark) would make it harder to trust third-party playbooks. But considering uPlaybook's use case (ansible-like system configuration) it feels like even with a restricted dialect it is going to have plenty of opportunity for nefarious purposes. I've put out uPlaybook for some limited review among my friends, and I've gotten some excitement about it. It doesn't have fleet management and remote running though, which is the big negative feedback I've gotten. I'm interested in thoughts on it though.

by kunley 3y ago

Cool. Ansible is still going to be around for some time. Also reminds me again that yaml should have never been born. Look how unnatural this "language" is in this article's examples

xienze 3y ago

Most of that is the embedded templating/scripting system (the stuff between {{}}), not YAML itself.

zufallsheld 3y ago
Well, that's Jinja. And arguably not a bad tool, but not the best for the use-case of config-management.
- kunley 3y ago
  Yeah, I just have this sentiment wishing that Ansible's author used own-crafted format. HashiCorp used their own and suddenly in this case no one says "yaml should be everywhere because it's everywhere already". In a similar mood, I wished Kubernetes was staying every from yaml. Even mentioned HCL would be better (although it's not perfect)
kunley 3y ago
Yes but the task names and parameters try to mimic natural language, like assert: that:, so you're supposed to read it as a whole, and it quickly turns into an abomination, with one syntax (yaml) for the structure and another (jinja) for values and conditions

avgcorrection 3y ago

Yeah. I don’t understand why we keep submitting ourselves to this way of working.

linsomniac 3y ago

IMHO, the issue is that Ansible uses YAML to do "programming language" sorts of things, which is why it feels so unnatural. I tried an experiment last year: What if Ansible had Python rather than YAML syntax. https://github.com/linsomniac/uplaybook?tab=readme-ov-file#simple-examples https://github.com/linsomniac/uplaybook?tab=readme-ov-file#s... The downside is that having full Python available makes it really easy to make your playbooks non-idempotent, which Ansible gate-keeps behind Ansible modules. Also someone raised a concern that full Python (rather than a more limited safe dialect like Starlark) would make it harder to trust third-party playbooks. But considering uPlaybook's use case (ansible-like system configuration) it feels like even with a restricted dialect it is going to have plenty of opportunity for nefarious purposes. I've put out uPlaybook for some limited review among my friends, and I've gotten some excitement about it. It doesn't have fleet management and remote running though, which is the big negative feedback I've gotten. I'm interested in thoughts on it though.