# Maintaining state of a set of machines which are not always up or connected

**URL:** <https://forum.ansible.com/t/maintaining-state-of-a-set-of-machines-which-are-not-always-up-or-connected/15437>\
**Category:** Ansible Project\
**Created:** [June 10, 2014, 4:25pm UTC](https://forum.ansible.com/t/maintaining-state-of-a-set-of-machines-which-are-not-always-up-or-connected/15437 "2014-06-10T16:25:23Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![eskhool](https://avatars.discourse-cdn.com/v4/letter/e/f14d63/32.png) [@eskhool](https://forum.ansible.com/u/eskhool)\
**Post date:** [June 10, 2014, 4:25pm UTC](https://forum.ansible.com/t/maintaining-state-of-a-set-of-machines-which-are-not-always-up-or-connected/15437/1 "2014-06-10T16:25:23Z")

</div>

what is the recommendation or best practice to apply a playbook to a set of machines which may often not be running? Shouldn’t there be a registry of which playbooks have been applied where? Even if playbooks are perfectly idempotent, it is highly inefficient to keep applying them again and again…

Would like to understand the suggested approach from the ansible designers for this use case before looking elsewhere/doing any dev work for the same

Thanks,  
eskhool

---

<div class="post-metadata">

**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\
**Post date:** [June 10, 2014, 11:24pm UTC](https://forum.ansible.com/t/maintaining-state-of-a-set-of-machines-which-are-not-always-up-or-connected/15437/2 "2014-06-10T23:24:33Z")

</div>

> what is the recommendation or best practice to apply a playbook to a set of  
> machines which may often not be running?

dynamic inventory might help you there.

> Shouldn't there be a registry of  
> which playbooks have been applied where? Even if playbooks are perfectly  
> idempotent, it is highly inefficient to keep applying them again and  
> again...

Not in my experience - I'd do some measurements before you spend too much  
time solving a problem that may not exist.

> Would like to understand the suggested approach from the ansible designers  
> for this use case before looking elsewhere/doing any dev work for the same

Have a quick read of [http://www.ansible.com/scaling-and-performance-whitepaper](http://www.ansible.com/scaling-and-performance-whitepaper)

Cheers,  
Dick.

---

<div class="post-metadata">

**Author:** ![Tomasz\_Kontusz](https://avatars.discourse-cdn.com/v4/letter/t/bc79bd/32.png) [@Tomasz\_Kontusz](https://forum.ansible.com/u/Tomasz_Kontusz)\
**Post date:** [June 11, 2014, 6:00am UTC](https://forum.ansible.com/t/maintaining-state-of-a-set-of-machines-which-are-not-always-up-or-connected/15437/3 "2014-06-11T06:00:34Z")

</div>

> what is the recommendation or best practice to apply a playbook to a set of  
> machines which may often not be running?

You might want to look at running ansible-pull on boot - then each machine will get into consistent state ASAP.  
But that takes some control from you, and can't really be used for orchestration.

> Shouldn't there be a registry of  
> which playbooks have been applied where? Even if playbooks are perfectly  
> idempotent, it is highly inefficient to keep applying them again and  
> again...

No, but you can build one pretty easily using callback plugins and a wrapper for filtering.  
Not that I think it's needed, as running a play on all machines is often as quick as running it on just the changed one. Modules do a pretty good job of not doing things that don't have to be done, and tasks are run in parallel, which means the only host slowing down a play is the one that you wanted to target anyway.

> Would like to understand the suggested approach from the ansible designers  
> for this use case before looking elsewhere/doing any dev work for the same

Well, I'm not an Ansible designer, but I still hope I had some useful suggestions 🙂

---

<div class="post-metadata">

**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\
**Post date:** [June 11, 2014, 6:24pm UTC](https://forum.ansible.com/t/maintaining-state-of-a-set-of-machines-which-are-not-always-up-or-connected/15437/4 "2014-06-11T18:24:29Z")

</div>

> what is the recommendation or best practice to apply a playbook to a set  
> of machines which may often not be running?

​Depends what behavior you want. Should it boot up if you want to run  
ansible on them, or should it fail?  
​

> Shouldn't there be a registry of which playbooks have been applied where?

​Not really. A fact cache is something in the pipeline AFAIK; would be nice  
also to be able to feed facts back from specific playbook outputs too (e.g.  
deployed version of things.)​

Even if playbooks are perfectly idempotent, it is highly inefficient to

> keep applying them again and again...

​Not sure why this is inefficient. You have lots of hosts? Also, why would  
you want to play them them again and again? Did you consider using --limit  
and/or --tags?

&nbsp;&nbsp;Serge

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\
**Post date:** [June 11, 2014, 10:41pm UTC](https://forum.ansible.com/t/maintaining-state-of-a-set-of-machines-which-are-not-always-up-or-connected/15437/5 "2014-06-11T22:41:33Z")

</div>

A really awesome solution here are the provisioning callbacks in Ansible tower.

Set up a cron tab that pings tower (anacron, firstboot, whatever) and when the machine checks in, ansible jobs will make sure that system gets the latest configuration.

This is better than ansible-pull because you get the centralized history, and it’s way easier to set up as well.

[http://www.ansible.com/tower](http://www.ansible.com/tower)
