# Nested facts get clobbered with an update to child fact

**URL:** <https://forum.ansible.com/t/nested-facts-get-clobbered-with-an-update-to-child-fact/22670>\
**Category:** Ansible Project\
**Created:** [September 29, 2016, 2:53am UTC](https://forum.ansible.com/t/nested-facts-get-clobbered-with-an-update-to-child-fact/22670 "2016-09-29T02:53:54Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![E.C\_Raymond](https://avatars.discourse-cdn.com/v4/letter/e/e19adc/32.png) [@E.C\_Raymond](https://forum.ansible.com/u/E.C_Raymond)\
**Post date:** [September 29, 2016, 2:53am UTC](https://forum.ansible.com/t/nested-facts-get-clobbered-with-an-update-to-child-fact/22670/1 "2016-09-29T02:53:54Z")

</div>

I am testing on both 1.9.4 and 2.1 and seeing the exact same behavior.

We have a fact.d generator that creates a tree of facts under ansible\_local. We use this to set defaults, but if during playbook execution it needs to update a default, it clobbers the entire ansible\_local parent fact. I created a test playbook to replicate the same issue.

> * * *
> 
> - hosts: localhost  
> connection: local  
> vars:  
> my\_roles:  
> info:  
> hardware: “CPU info”  
> cmdb:  
> local: [{‘name’:‘blah’}]  
> remote: False
> 
> tasks:
> 
> - name: set new facts  
> set\_fact:  
> args:  
> test\_dict: {‘name’: meh’}
> 
> - name: test  
> set\_fact:  
> args:  
> my\_roles:  
> cmdb:  
> local: “{{ my\_roles.cmdb.local + ([test\_dict]|list) }}”  
> remote: True
> 
> - debug: var=my\_roles

> PLAY [localhost] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
> 
> TASK [setup] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
> ok: [localhost]
> 
> TASK [set facts] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
> ok: [localhost]
> 
> TASK [test] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
> ok: [localhost]
> 
> TASK [debug] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
> ok: [localhost] =\> {  
> “my\_roles”: {  
> “cmdb”: {  
> “local”: [  
> {  
> “name”: “blah”  
> },  
> {  
> “name”: “meh”  
> }  
> ],  
> “remote”: true  
> }  
> }  
> }
> 
> PLAY RECAP \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
> localhost : ok=4 changed=0 unreachable=0 failed=0

As you can see, the playbook clobbers the parent my\_roles and updates with whatever is in the set\_fact task. I have read through various documentation links, and searched around but have not seen anyone come across this specifically. I understand that ansible uses everything as a string, so taking a fact and then updating obliterates the original fact, but how does one update a nested fact in Ansible?

---

<div class="post-metadata">

**Author:** ![Nick](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@Nick](https://forum.ansible.com/u/Nick)\
**Post date:** [September 30, 2016, 9:41am UTC](https://forum.ansible.com/t/nested-facts-get-clobbered-with-an-update-to-child-fact/22670/2 "2016-09-30T09:41:51Z")

</div>

I'm no authority, for instance I've not switched to using 2.x versions of Ansible since I got an essentially functional setup, but I'll chip in and say I \*think\* this is normal behaviour when variable scopes are composed.

I used to try and nest role variables into hierarchies but a long time ago decided this was simply too fraught when composing them (and this not even using set\_fact). I started treating them as globals (albeit "with structure"), and naming them with prefixes accordingly: replace underscores for dots. This resolved my problems at the time.

If it wasn't or is no longer the case, I'd be interested to hear about it, I'm not aware of anything in the docs which describe scope composition rules in this level of detail.

N