I've got an ever expanding playbook that patches a few hundred machines to the latest version, I just add the same role with different parameters.

Obviously, the playbook is taking longer and longer to run on each machine, even though it's not really doing anything on them.

What I'm doing is in the pre-tasks, I'm getting a changelog file, checking that and running each of the roles when an identifier that a successful run puts in that changelog file does not exist. But, even so, ansible still takes a fairly onerous amount of time to do nothing.

When I strace the main ansible process it looks like its trying to hit a bunch of non-existent cached facts files and the inventory script.

I think I've created the dynamic inventory correctly, it accepts both the "--host" and "--list" parameters (although I'm not certain that --host is being called).

I've got about 100 devices that I haven't gathered facts for in the inventory file and I've got:

fact_caching_connection = /tmp/factscache
fact_caching = jsonfile

set up.

If I take that out, it doesn't try to hit up the missing facts files, but it there is a stat in the strace against the inventory generator file over and over again. I know it can't be generating the entire inventory because that take 5 seconds.

I've tried generating regular inventory files and using those, I've tried generating inventory files with both _meta and the regular host_vars (currently using _meta to house the host vars because I heard that was faster).

(running ansible 2.0)

  • What does the debug log say? Looks like there is a kind of snow ball effect.
    – 030
    Commented Apr 23, 2017 at 18:01
  • Have you tried using: gather_facts: no when possible? and are you using gathering: smart or gathering: explicit? The gathering lines are probably the most important when using fact_caching
    – gdahlm
    Commented May 21, 2017 at 19:28
  • @gda I I have gather facts on, but I think I'd only take a speed hit on facts gathering on the first task, so it wouldn't make no-ops's worse. Gathering is set to smart
    – Peter Turner
    Commented May 22, 2017 at 17:29

2 Answers 2


Instead of storing the Ansible code centrally, one could extract the code and distribute it to every project. Another benefit of this approach is that config and code will be seen together and that developers will change config and Ops could fix e.g. bugs instead of working in silos. Running the code per project will prevent that the executions will take longer, longer and longer.


You could isolate the roles and run just them, you can generate a static inventory list before you run the particular role(and it's associated task).

Make sure that the task doesn't have a whole lot of inheriting/dependant roles. As 030 mentioned, it might be a good idea to implement some kind of way to semantically separate the roles.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.