mjhjmtu

I know that an idempotent function returns a result which is can be returned more than once without changing the application essentially (like adding zero to a number or multiplying that number by 1).

doing some_package_manager upgrade X -y via Ansible's state=latest + a cron schedule isn't idempotent in that sense because the result does change the application essentially; each new upgrade has new features.

So where, why and when did the notion of an "Idempotent Ansible ad-hok command/playbook" appeared?

"Idempotence" is a property often ascribed to configuration management systems, of which Ansible is only one example. Puppet also describes itself as idempotent; like Ansible, it would be more accurate to say "quasi-idempotent", because they both offer ways to break strict idempotence.

I think your question is partly motivated by a misunderstanding about the more formal meaning of idempotence, which is a operation that will always give the same result no matter how many times you apply it.

Although adding zero or multiplying by one both satisfy the definition of idempotency, they are what we might call trivially idempotent. They are no-ops, and in general idempotence need not be a no-op.

Some examples that might help you get at the more general intuition for idempotence:

• Dividing a number by itself.


• Subtracting a number from itself.


• Flattening a 3D object onto a surface: once it is flattened, flattening it more will not change its shape further.


• Burning a log: once it is completely burned, applying more flame to it will not burn it further.


• Using a spoon to dissolve coffee into hot water: once the coffee is dissolved, further stirring will not make it "more dissolved".


• Telling a dog to "sit": it will have an effect the first time, but subsequent commands to sit will not produce change.


• Copying a configuration file from one computer to another: once it is copied the first time, copying the file again will not change the destination file any further.

The last two examples get most closely at what is meant by idempotence in the context of configuration management systems. At their simplest, they are about putting the remote machine into a desired state, by either copying files or issuing commands. Once the remote is in that state it should/will have no effect to copy the files or issue the commands again.

The reason idempotence is marketed as a desirable property of configuration management systems like Ansible or Puppet is that when managing a large number of servers, it is most convenient if as many of them as possible have the same configuration as each other. To enforce uniformity, you copy over the required configuration files, set their firewalls the same way, etc. But it is desirable to be able to do this repetitively, because when running a big farm of servers you don't want to waste time figuring out which ones have deviated slightly because of some maintenance or upgrade. You just want to be able to tell all the servers at once: "adopt the preferred configuration".

It is like if you are trying to manage a roomful of dogs, and you want them all to be seated: some of them are sitting already, but others are standing. Issuing the "sit" command will not affect the ones already seated, but it will bring the whole room into the desired uniform configuration.