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/CAGYSzJ9AT3HyNG-N%2Bz4oTJYspQ72DtZrO1AAMM30raf2s6pbQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
