iden/idem - I am one of those mathematicians who can't figure out why 'identically' 'potent/powerful' should turn into ideMpotent. Apologies for my bad spelling!
On Tuesday, December 13, 2016 at 10:13:47 AM UTC, Bit Divine wrote: > > > 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/a548375a-d8ea-49b1-b2a8-7a4817d708d6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
