We've discussed fact caching options in the past.
There may be some in the future.
Until now, talk to the hosts first.
On Thu, Jun 5, 2014 at 11:14 AM, Dick Davies d...@hellooperator.net wrote:
Is there an option to use the FQDNs in the inventory itself then?
If they resolve then you
Is there an option to use the FQDNs in the inventory itself then?
If they resolve then you don't need to facts gather, right?
On 4 June 2014 16:50, Michael Mahemoff mich...@mahemoff.com wrote:
True, the dummy boilerplate is small, but it has to precede every playbook.
(I also thought it had to
It's really not bad, the dummy play just looks like this:
- hosts: all
And that's it, followed by other plays. You can limit it more of course, if
you don't need facts about every system in your inventory, but the setup
step needs to be run on systems to get their facts. However it only needs
to
But it gets more unwieldy if you're using roles. If my app role needs
to have the IPs for the databases I just have to hope that the
playbook that ends up running the tasks in my play have gathered all
the facts from those other systems. It gets even more
action-at-a-distance when your role is a
True, the dummy boilerplate is small, but it has to precede every playbook.
(I also thought it had to include at least one task to be in effect.)
The main issue is performance. I'm not dynamically provisioning, so these
things never change. I thought maybe there's some trick people are using to
I know this has come up before, but I've not come across a real answer for
it.
It's common for a given host to depend on other hosts. App servers need to
know the IP of databases they consume, databases need to know IPs of app
servers that will be accessing them etc etc. In Ansible, the IP of
