That's exactly what I'm looking for, please implement it with "gather_facts: force" - in playbook to override --limit & --tags settings. Is there any way to push it to official release? vote?
BR Dmtiry Z. On Saturday, October 18, 2014 1:31:58 PM UTC-7, Craig Tracey wrote: > > 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]> >> 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]. >>> 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/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/e97226fb-a3a4-49c9-9d7c-aa65d86bf69b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
