Given the following variables in the context of a jinja2 render (whether at the task level or in a template):
{‘my_var’: {‘x’: ‘{{y}}’}, ‘y’:‘foon’}
Ansible will automatically convert any {{my_var.x}} reference into ‘foon’; literally, it automatically recurses until ‘{{’ no longer exists.
Now, this actually can be kind of useful if you think about usage of it in host vars or group vars- doing something like ‘{{(ansible_memtotal_mb * .5)|int}}’ in a group_var definition to set a sane default for something while allowing the host to override it if it wants.
I’m not entirely sure this was actually intended functionality though; it looks to be a quirk that works and is potentially useful, but not necessary designed for.
Should this be allowed?
If not, it’s pretty damn simple to disable- the attached patch addresses it. If this is intended to be allowed, the functionality needs a few fixes (which should move over to an issue I suspect):
- self referential structures don’t work. my_conf: {‘x’ : ‘{{my_conf.y * 2}}’, ‘y’: 2} doesn’t work due to ansible.utils.template._jinja2_vars trying to force a full rendering of my_conf up front, rather than resolving as it goes.
- Because of how it’s implemented, if you have ‘{{blah}}’ as a value in any variables, you must explicitly escape it else it’ll always render (and fail if the ‘blah’ variable doesn’t exist).
Which direction should this go? Disable the nested support, or fix it?