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 <[email protected] > <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 <[email protected]> >>> 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" <[email protected]> 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 [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> >>>>>> 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 [email protected]. >>>> To post to this group, send email to [email protected]. >>>> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <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 [email protected]. To post to this group, send email to [email protected]. 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.
