3 ms·

Most of the ansible roles I come across written by my team are not idempotent either, its a huge lie that Ansible is idempotent. Its idempotent if you put the e

Most of the ansible roles I come across written by my team are not idempotent either, its a huge lie that Ansible is idempotent. Its idempotent if you put the effort into make it be but if I see tons of shell or command module invocations without prerequisite checks to see if the work should be done. Most devs I see using Ansible treat it like a shell script written in YAML and to that purpose it sucks.

LanternLight83 5y ago
I can appreciate that I learned the term idompotency from working with Ansible, but I think they failed to really make it a feature of the language- it could have been a stronger default, explicit, like Unsafe in Rust. As it stands, writing idempotent Ansible takes as much discipline and intentionality as any other language, and can prevent integrating roles that other's have written without such discipline. There is value in it, but not in respect to idempotentcy as any sort of inherent principal (at least outside of the std lib, which is ofc pretty great abt it).
Too 5y ago
This. The built in tasks only get you so far. If you have anything custom you have to create the task for it yourself, with idempotency in mind, at which point you might as well have the exact same logic in a ./install.py file. Even with the standard library of predefined task, most devs don't put in the effort to learn them since "ifconfig | grep" and other commands are baked into their muscle memory, they would rather make a quick and dirty bash-step than figure out what is the best practice ansible-equivalent. In the end the result is a sequential shell script written in yaml with no guard rails keeping it idempotent, plus riddled with jinja template-substitutions making it a nightmare to follow. A truly declarative system would be designed more like makefiles, really enforcing idempotence. With steps in playbooks being executed in sequence it's too easy to fall back to script-thinking and side-effects. Sadly i'm not aware of any.

LanternLight83 5y ago

I can appreciate that I learned the term idompotency from working with Ansible, but I think they failed to really make it a feature of the language- it could have been a stronger default, explicit, like Unsafe in Rust. As it stands, writing idempotent Ansible takes as much discipline and intentionality as any other language, and can prevent integrating roles that other's have written without such discipline. There is value in it, but not in respect to idempotentcy as any sort of inherent principal (at least outside of the std lib, which is ofc pretty great abt it).

Too 5y ago

This. The built in tasks only get you so far. If you have anything custom you have to create the task for it yourself, with idempotency in mind, at which point you might as well have the exact same logic in a ./install.py file. Even with the standard library of predefined task, most devs don't put in the effort to learn them since "ifconfig | grep" and other commands are baked into their muscle memory, they would rather make a quick and dirty bash-step than figure out what is the best practice ansible-equivalent. In the end the result is a sequential shell script written in yaml with no guard rails keeping it idempotent, plus riddled with jinja template-substitutions making it a nightmare to follow. A truly declarative system would be designed more like makefiles, really enforcing idempotence. With steps in playbooks being executed in sequence it's too easy to fall back to script-thinking and side-effects. Sadly i'm not aware of any.