Answers: <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-14T09:33:57.283Z
Answers: 2017-08-14T09:33:57.283Z
Answers: 030
Answers: <p>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).</p>
  
  <p>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.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-14T16:32:15.963Z
Answers: 2017-08-14T16:32:15.963Z
Answers: HackToHell
Body: <p>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.   </p>
  
  <p>Obviously, the playbook is taking longer and longer to run on each machine, even though it's not really doing anything on them. </p>
  
  <p>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.  </p>
  
  <p>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.</p>
  
  <p>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).  </p>
  
  <p>I've got about 100 devices that I haven't gathered facts for in the inventory file and I've got:</p>
  
  <pre><code>fact_caching_connection = /tmp/factscache
  fact_caching = jsonfile
  </code></pre>
  
  <p>set up.  </p>
  
  <p>If I take that out, it doesn't try to hit up the missing facts files, but it there is a <code>stat</code> 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.</p>
  
  <p>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).  </p>
  
  <p>(running ansible 2.0) </p>
  
Comments: CC BY-SA 3.0
Comments: 2017-04-23T18:01:57.690Z
Comments: What does the debug log say? Looks like there is a kind of snow ball effect.
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2017-05-21T19:28:39.503Z
Comments: 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`
Comments: gdahlm
Comments: CC BY-SA 3.0
Comments: 2017-05-22T17:29:59.617Z
Comments: @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
Comments: Peter Turner
Tags: <ansible>
Title: Running Ansible no-op's faster with a dynamic inventory and cached facts files
UserDisplayName: Peter Turner
ThreadText: # Running Ansible no-op's faster with a dynamic inventory and cached facts files
  
  (Asked by: username_0 on 2017-04-19)
  
  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)
  
  **Tags:** ansible
  
  > **Comments:**
  > **username_1**: What does the debug log say? Looks like there is a kind of snow ball effect.  
  > **username_2**: 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`  
  > **username_0**: @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  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-08-14. Score: 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.
  
  
  ---
  
  ### Answer by username_3 on 2017-08-14. Score: 1
  
  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.
  
  
  ---
  
  