A criticism of Ansible being that it's not declarative, in that, if it's used to spin up n number VM's, and then need an additional one, it's not n+1 but just 1.


Playbooks and Idempotency Idempotent is a fancy word that means that you can do something multiple times and the outcome will be the same. In Ansible terms, a playbook is considered idempotent if you can run it multiple times and after the first run the machine is in a certain state, which doesn’t change if you run the same playbook again at any point in time after that. Take the playbook that you just wrote, for example. The first time that you ran it, it evaluated your playbook and applied the necessary transformations to ensure that PHP, nginx, and MySQL were installed. You can see that in the Ansible output it says that things were changed:


Ansible: From Beginner to Pro Michael Heap Reading, Berkshire United Kingdom ISBN-13 (pbk): 978-1-4842-1660-6 DOI 10.1007/978-1-4842-1659-0 ISBN-13 (electronic): 978-1-4842-1659-0 Library of Congress Control Number: 2016952799 Copyright © 2016 by Michael Heap

my reading of the above would be that Ansible is declaritve in that, if additional VM's are needed, to provision then for the total. Is that a correct understanding?

the specific criticism being that:

Over time, as you apply more and more updates, each server builds up a unique history of changes. This often leads to a phenomenon known as configuration drift, where each server becomes slightly different than all the others, leading to subtle configuration bugs that are difficult to diagnose and nearly impossible to reproduce.

which seems at odds with the Apress text.

Or,perhaps, they're saying, that you might run a playbook. Then additional changes are needed. So, those changes are incorporated, and this constitutes the above "configuration drift"?

  • 2
    I would go so far as to say that both sides of this argument rely on straw men. Yes, ansible is declarative, but if you use features which destroy idempotency -- for example using shell or command unconditionally -- then you can introduce configuration drift. Terraform too can be abused to make it look "not declarative" (userdata in instances will force recreation of resources even if they haven't changed). I'm not sure this is an argument worth having, since so much depends on the context in which these tools are doing their job. – Bruce Becker Dec 8 '20 at 8:28
  • 2
    Also it depends on the level of "control". For example a list of 3 year old VMs (originally installed with Debian 9) are upgraded automatically to Debian 10 and then you add a new VM fresh installed with Debian 10, you'll see differences at all (for example eth0 or ens18). If you're aware of this possible changes (by controlling ALL configurations on a host - like completly /etc/* and have a list of all libs and the inventory knows about all packages and all distribution specific changes) - then maybe there is no drift. – TRW Jan 16 at 18:06
  • 2
    But of course an older machine differs from a new machine - because nobody wants that control. We're all lucky about the package maintainer and their work and the "basic setup". Sometimes they change the behaviour and you don't see it. There is no practicle chance to have no drift - but maybe - because you have an automatism to install a VM - just throw away a VM randomly and install a new one. – TRW Jan 16 at 18:06
  • If there is drift, it's because of things that you're not controlling. And if you're not controlling them, you don't care about them so therefore, they're irrelevant. Don't worry about it. – colan Feb 5 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.