"but wouldn't we want debug: var=hostvars to not come from the cache and be
the latest truth of what is contained in hostvars"

Serge mispoke a bit above.  The problem is not that hostvars is a cache,
but rather that hostvars is an object that provides access to individual
variables.

We aren't really concerned with:

- debug: var=hostvars

as it's a very unusual thing to do.

typically this is how vars are shown with debug:

- hosts: webservers
  tasks:
     - debug: var=foo

And the "hostvars" trick is only needed when accessing variables from
*other* servers, typically in templates for instance when building out
something like an iptables config.





On Thu, Oct 23, 2014 at 9:50 AM, Michael Hoglan <mhog...@gmail.com> wrote:

> I know there probably internal implementation details on why it is the way
> it is, but wouldn't we want debug: var=hostvars to not come from the cache
> and be the latest truth of what is contained in hostvars?  If I am doing a
> debug of the variable, I am already in a mode where performance is not a
> concern, I am trying to gather insight into the state of the system.  So
> maybe if the debug task is used, the variable in the task should be fully
> interpolated, or unioned with the rest of dictionaries / lists that are
> accessed when specifying hostvars[hostname]
>
>
> Thanks!
> Michael
>
> On Thursday, October 23, 2014 2:22:26 AM UTC-5, Serge van Ginderachter
> wrote:
>>
>>
>>
>> On 20 October 2014 23:12, Michael DeHaan <mic...@ansible.com> wrote:
>>
>>> "I *think* that debug: var=hostvars should print all the variables in
>>> scope (for each host)"
>>>
>>> It doesn't do this, but rather looks for variable names inside hostvars.
>>>
>>> You can think of the "hostvars" syntax as a way to reference variables
>>> for other hosts.
>>>
>>> I guess whether it should work might be a technicality, but that's what
>>> it was intended for.
>>>
>>
>>
>> ​Yes, 'hostvars' is implemented  as a caching dictionary, which means you
>> need to explicitly request vars for a particular key/host.​
>>
>>  --
> 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-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/92b037c6-d24b-48d4-9d7d-1135e4c70e32%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/92b037c6-d24b-48d4-9d7d-1135e4c70e32%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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxiJ-gfnMgyfq3HCJtk_uJNR9Aa14rQbKLwx6vq9w-%2BAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to