"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 <[email protected]> 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 <[email protected]> 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 [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/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 [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/CA%2BnsWgxiJ-gfnMgyfq3HCJtk_uJNR9Aa14rQbKLwx6vq9w-%2BAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
