# Figuring out playbook\_vars\_root

**URL:** <https://forum.ansible.com/t/figuring-out-playbook-vars-root/26867>\
**Category:** Ansible Project\
**Created:** [February 28, 2018, 9:10am UTC](https://forum.ansible.com/t/figuring-out-playbook-vars-root/26867 "2018-02-28T09:10:09Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jean\_Helou](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@Jean\_Helou](https://forum.ansible.com/u/Jean_Helou)\
**Post date:** [February 28, 2018, 9:10am UTC](https://forum.ansible.com/t/figuring-out-playbook-vars-root/26867/1 "2018-02-28T09:10:09Z")

</div>

I am trying to understand what playbook\_vars\_root does in Ansible 2.4.3, I have the feeling that it is totally ignored

According to the [documentation](http://docs.ansible.com/ansible/2.4/config.html#playbook-vars-root) :

> This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host\_vars/group\_vars The top option follows the traditional behaviour of using the top playbook in the chain to find the root directory. The bottom option follows the 2.4.0 behaviour of using the current playbook to find the root directory. The all option examines from the first parent to the current playbook.

Despite my efforts, I can’t seem to get anything else than the “bottom” behaviour.

I have the following tree

─ ansible.cfg  
├── group\_vars  
│ └── foo  
│ └── vars.yml  
├── host\_vars  
│ └── localhost.yml  
├── inventories  
│ └── site.lst  
├── main.yml  
└── playbooks  
└── sub.yml

ansible.cfg

[defaults]  
playbook\_vars\_root = top

site.lst contains the following

[foo]  
localhost ansible\_connection=local

group\_vars/foo/vars.yml

---

<div class="post-metadata">

**Author:** ![Jean\_Helou](https://avatars.discourse-cdn.com/v4/letter/j/a9adbd/32.png) [@Jean\_Helou](https://forum.ansible.com/u/Jean_Helou)\
**Post date:** [February 28, 2018, 9:53am UTC](https://forum.ansible.com/t/figuring-out-playbook-vars-root/26867/2 "2018-02-28T09:53:06Z")

</div>

Looking further into this I find conflicting information (maybe I understand it all wrong)

In [https://github.com/ansible/ansible/issues/33177#issuecomment-356976272](https://github.com/ansible/ansible/issues/33177#issuecomment-356976272) (“when including playbook, group\_vars of original playbook are ignored”) @sivel says :

We have discussed this in the Core Team Meeting on Jan 11, 2018.

After looking at the code previous to 2.4, and discussing what our expectations are, we have decided that the previous behavior was a bug, and we will not be adding functionality to mimic the pre 2.4 behavior.

but in [https://github.com/ansible/ansible/issues/29008#issuecomment-330558987](https://github.com/ansible/ansible/issues/29008#issuecomment-330558987) (“import\_playbook from child directory break var scope”) @bcoca says :

The fix we are planning does 2 things:

- keep a ‘stack’ of playbook paths, starting with the initial playbook and ending with the ‘current’ one
- group/host\_vars processing should got through each path in order

So ‘initial playbook’ and the ‘current playbook’ adjacent group/host\_vars will all be read (as well as any intermediate ones). This is still a change from previous behaviour but we believe this is the ‘most’ correct way of dealing with the variables.

in [https://github.com/ansible/ansible/issues/32936#issuecomment-352700117](https://github.com/ansible/ansible/issues/32936#issuecomment-352700117) (“Host variables adjacent to master playbook are unavailable to included tasks”) @lufik also mentions

The PLAYBOOK\_VARS\_ROOT config doesn’t change anything (it’s only task related not playbook related). Shortly \>=2.4.0 breaks the backward compatibility for including playbooks (maybe the caption of this issue should be changed also).

the code does seem to be in agreement ([https://github.com/ansible/ansible/blob/stable-2.4/lib/ansible/vars/manager.py#L246](https://github.com/ansible/ansible/blob/stable-2.4/lib/ansible/vars/manager.py#L246)) though I am not familiar with the code base but I fail to see the differences between all 3 issues … they all seem to have a structure similar to what I used in my experimentation.