I too love things to be idenpotent. It is no accident that `check or (install and check again)` is automatically idempotent. :-)
On Monday, December 12, 2016 at 3:11:42 PM UTC, Spike Robinson wrote: > > I'm kind of with BitDivine. I've been using Ansible "in anger" (at times > literally!) on a real world environment for a few months now. I also try to > make my playbooks a statement of desired state. Most of the time that's > easy to achieve. It gets frustrating when it's not so easy to achieve, but > each of those challenges has pushed me up the learning curve of the > language, so it's all good. As Michael says in the OP, it's easy (and good) > to write scripts in plain English, and once written they stay written and > useful, you can forget about them and still rely on them. > > I also try to write idempotent scripts. Again, this is easy often enough > that in the cases when it isn't so easy, it gets frustrating. You can see > from the varying functioning and usage of the various modules that > idempotence is probably one of the "computer-sciencey" "memes" that the OP > disdains. It's a general principle for modules, maybe, but it's far from > rigidly enforced or universal or uniform. Or in some cases, it's so taken > for granted that you can't see from the documentation how idempotence is > going to work, but then magically it "just does". I'm learning that with > Ansible sometimes you just have to close your eyes and *believe*. :-) > > "Install then (check or install)" is a good pattern. Running the script > until it goes green is a much easier meta-pattern (a behavior pattern > rather than a programming pattern). It's a great habit to get into and on > our site we are doing it all the time. (Along with, while testing the > playbook, actually checking the system *hasn't* changed when the playbook > responds green!) Again, the fact that this "just works" most of the time > makes it doubly frustrating when, for example, tests that perform no actual > system change report Changed by default, or, worse, tests like (the touch > module) actually do change the system when executing what should be a read > only test. > > So I can see the merits of all the approaches mentioned here. :-) -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/453aac81-d8a3-42e3-8b2c-65626007241e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
