Force fact-gathering on all hosts when using -limit

[Christian Franke]

Hi all,

I'm sitting in front of a fairly complex ansible project that we're using to set up our local development environments (multiple VMs) and there's one role that uses the facts gathere by ansible to set up the etc/hosts file on every VM. Unfortunately, when you want to run the playbook for one host only (using the -limit parameter) the facts from the other hosts are (obviously) missing.

Is there a way to force ansible to gather facts on all hosts, even if you limit the playbook to one specific host?

We tried to add a play to the playbook to gather facts from all hosts, but of course that also gets limited to the one host given by the -limit parameter. If there'd be a way to force this play to run on all hosts before the other plays, that would be perfect.

I've found the solution to use fact caching with redis, but since our playbook is used locally, I wanted to avoid the need for additional software. I know, it's not a big deal, but I was just looking for a "cleaner", ansible-only solution and was wondering, if that would exist.

Cheers,

Christian

[Josh Smift]

CF> Is there a way to force ansible to gather facts on all hosts, even if
CF> you limit the playbook to one specific host?

If you don't have to use --limit per se to do it, you can get much the
same effect with something like this:

- hosts: all
gather_facts: true

- hosts: "{{ targets }}"
[* stuff *]

Then you can run this with --extra-vars="targets=<expression>", and the
second play will only run on hosts that match the expression.

-Josh (j...@care.com)



This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.

[Brian Coca]

Another way around this is using persistent fact caching.

--
Brian Coca

[Michael Peters]

I have to say, that it kind of bothers me that fact "caching" is the
solution to whether or not it works. Caching is normally about
speeding things up or making them more scalable. Not about having it
actually be correct. In this instance, wouldn't relying on fact
caching break every time the cache is flushed, or on a new system that
was not loaded with the cache?

--
Michael Peters

> --
> 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/CAJ5XC8kf5An9BvRX%2BUb2Bcw%2BuQ04ZV%3D_rozQAkNqp3BdnmG_Kw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Brian Coca]

It is not the solution, but it is a workaround available now.

On my list i have being able to 'delegate' facts so we can do something like:

setup: set_for={{item}}
delegate_to: "{{item}}'
with_items: "{{groups['dbservers']}}

but my list is long and this is not a simple task.
--
Brian Coca

[Michael Peters]

Gotcha, thanks!

> --
> 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/CAJ5XC8%3DVbKYAqRMAJpeDNBSSC6%2BfJGrO9heu2oe2dgvk9_XiHA%40mail.gmail.com.