Somewhat OT, but I think lots of people coming from certain other tools might not know what this word means, and are saying it too frequently :) I've seen it crop up in bug reports a fair amount, "X is not idempotent", etc, and in 86.2% of the occurances, the word "idempotent" is being used incorrectly.
All this word means is an operation is repeatable. In math, it means F(x) = F(F(x)) That's it. Our modules all are repeatable just like that, so it's not really interesting to use that word so much. A more interesting property is does a module get you to the desired state you want to be in regardless of the desired state. That's somewhat related, but not quite the same thing. This is why Microsoft named their configuration tools, quite uninterestingly, "Desired State Configuration", not "Impotent State Configuration". (However, awkward product name! Sorry, guys!) The classic analogy is driving across the country. If I want to get to California, driving west from North Carolina gets me there, driving north from Tijuana gets me there. But you don't put "drive west" in your automation because you are not sure if you are driving from NC or Mexico. The idempotence in this property is that you stop driving when you get to California if you run the "drive to California" routine again. The more important property is can you specify the location and have it get you there. If there was a bug in a module and you ended up in Maine, the bug is not "driving module is not idempotent". The bug is "driving module has some crazy messed up logic in it". I think "idempotence" has somehow become the new "um" of conversation, and folks like to insert it in many sentences to make things sound complicated. Don't do that! :) This Desired State thing also gets mislabelled from time to time as "Convergence". Convergence typically means if I run this process 4 or 5 times it gets to where I want to be. Terrible, you want to get there in one hop! Why do you want a module or system that only fixes half of the problem at a time? Anyway, meh. Convergence would be like "drive to California -- ok you are in Nevada -- drive to California - ok, you are in California". No, you don't want stuff to converge, you want it to do what you say. I think the industry is plagued a bit with the idea that simple things must be talked about in complicated terms, and Ansible is not like that. Our goals are simple -- Speak in plain English. Get stuff done. Thus, if you see me bristle up a little bit when I get a academic email or bug report, that's why. It's how we (as a project) think. We want to talk about computers and make things easy, not harder. Yes, desired state, idempotence, we have those properties of software systems. They are uninteresting properties though. What's interesting? Getting work done! I guess my general point is there's a risk -- for some crazy reason -- to make computers hard to talk about. Computers are already hard. My challenge to the world is to talk about them simply. As we attact users from other configuration tools, encourage simple dialog. Computers are complicated enough already. -- Michael DeHaan <[email protected]> CTO, AnsibleWorks, Inc. http://www.ansibleworks.com/ -- 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]. For more options, visit https://groups.google.com/groups/opt_out.
