I also have this issue with some playbooks that we have. Michael, nice work on the caching! While fact caching is definitely useful and something that we will likely implement, I also liked the idea of 'gather_facts_force.' Therefore, I have gone ahead an implemented this via pull request:
https://github.com/ansible/ansible/pull/9377 Let me know what you all think. Best, Craig On Friday, August 15, 2014 10:54:30 AM UTC-4, Michael DeHaan wrote: > > Great! > > Yep, these are part of the live docs now: > > http://docs.ansible.com/playbooks_variables.html#fact-caching > > > > > > On Fri, Aug 15, 2014 at 9:21 AM, Thijs Cadier <th...@appsignal.com > <javascript:>> wrote: > >> Awesome, works like a charm. The docs in this commit were helpful as >> well: >> https://github.com/ansible/ansible/commit/160ddf6b046c1a7976f356ed02d506223b6cd0ae >> >> >> On Friday, August 15, 2014 12:33:00 AM UTC+2, Michael DeHaan wrote: >> >>> Yes. >>> >>> Apologies for the weird archive link instead of the forum, but this is >>> what Google juice turned up when I was looking for my post. >>> >>> https://www.mail-archive.com/ansible-project@googlegroups. >>> com/msg07964.html >>> >>> >>> >>> >>> On Thu, Aug 14, 2014 at 12:26 PM, Thijs Cadier <th...@appsignal.com> >>> wrote: >>> >>>> Any news or other workarounds for this? We've now converted our staging >>>> system to Ansible, but not sure how I can roll out to production. The >>>> problem is that we use the inventory set up hosts files and firewall >>>> rules, >>>> but we can't run Ansible on the entire production cluster for the >>>> migration. We need to do it host by host and check the state in between. >>>> Does anybody know of any workarounds to do this? >>>> >>>> >>>> >>>> On Wednesday, July 16, 2014 6:28:41 AM UTC+2, Henry Finucane wrote: >>>> >>>>> I have a similar problem with a more limited scope- I'd like to be >>>>> able to inspect group variables as applied to hosts without gathering >>>>> facts >>>>> everywhere- I use them to generate monitoring configuration. >>>>> >>>>> It's a little intractable because they could be dynamic and depend on >>>>> fact gathered variables, but I'd be happy dealing with that restriction. >>>>> On Jul 15, 2014 9:21 PM, "Thijs Cadier" <th...@80beans.com> wrote: >>>>> >>>>>> I'm also running into this. Would be great if there was a way to >>>>>> enable fact gathering for all (or possibly a subset of) hosts when >>>>>> scoping >>>>>> on tags or hosts. Without something like that you always have to run on >>>>>> all >>>>>> machines to be able to get a list of ip addresses of machines for a >>>>>> firewall config, for example. >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, September 10, 2013 3:22:34 PM UTC+2, Nick Groenen wrote: >>>>>>> >>>>>>> I have a very large playbook which configures our entire >>>>>>> infrastructure. Because of this, various steps are tagged so that >>>>>>> only >>>>>>> specific parts of the playbook can be run, cutting down on runtime >>>>>>> when required. >>>>>>> >>>>>>> Parts of this setup use facts/hostvars to automatically create >>>>>>> correct >>>>>>> configuration files. For example, nginx config adding all the >>>>>>> application servers that are defined in the inventory to the correct >>>>>>> upstream definitions, and iptables on the appservers automatically >>>>>>> opening up the correct ports to the loadbalancers. >>>>>>> >>>>>>> However, when running the playbook with --limit, or --tags, not all >>>>>>> hosts are contacted, and as a result, facts aren't available on >>>>>>> every >>>>>>> system in the infrastructure. This causes all kinds of problems for >>>>>>> my >>>>>>> setup, obviously. >>>>>>> >>>>>>> Is there any way to force gathering of facts on all hosts, even when >>>>>>> specifying one of these options? Or another way to deal with this >>>>>>> situation that I haven't thought of? >>>>>>> >>>>>>> Right now, I'm solving it for the --tags case by having one task at >>>>>>> the start of the playbook, which simply calls the ping module and >>>>>>> has >>>>>>> every tag that's used listed. This way, this task is kicked off no >>>>>>> matter which tag is specified, causing facts to be gathered on every >>>>>>> system in our inventory. >>>>>>> >>>>>>> Obviously, this isn't a practical solution however, nor does it >>>>>>> solve >>>>>>> the case where limit it used. >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Ansible Project" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to ansible-proje...@googlegroups.com. >>>>>> To post to this group, send email to ansible...@googlegroups.com. >>>>>> >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/ansible-project/2c0c5d72-132b-4fd4-adfe-448284d02ad5% >>>>>> 40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/ansible-project/2c0c5d72-132b-4fd4-adfe-448284d02ad5%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Ansible Project" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to ansible-proje...@googlegroups.com. >>>> To post to this group, send email to ansible...@googlegroups.com. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/ansible-project/c2743a71-a463-4f41-89cb- >>>> fd09318012df%40googlegroups.com >>>> <https://groups.google.com/d/msgid/ansible-project/c2743a71-a463-4f41-89cb-fd09318012df%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ansible-proje...@googlegroups.com <javascript:>. >> To post to this group, send email to ansible...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/ansible-project/1e0afa48-cf21-4301-84b3-20715725cb1c%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ansible-project/1e0afa48-cf21-4301-84b3-20715725cb1c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/c4496707-9457-41a6-bc63-df762df9f233%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
