variable inheritance as dict within template

114 views
Skip to first unread message

Matt Peterson

unread,
Jun 29, 2014, 4:52:44 PM6/29/14
to ansible...@googlegroups.com
Howdy,

It appears that most variables and dict values are correctly inherited into jinja2 templates, however I appear to have found some corner case or known limitation. I've been skimming both the Ansible & Jinja2 docs and have yet to find a working solution - my guess is incompatible YAML syntax. Assuming the following host_vars:

---
uniq_id: 255

vlans: {
  2: {
    description: "working VLAN 2 on unique host {{ uniq_id }}",
    v4_cidr: "192.168.1.1/24",
  },
  5: {
    description: "another example",
    v4_cidr: "172.16.230.1/24",
  },
  "{{ uniq_id }}": {
    description: "not working",
  }
}

Using the following template:

Working dict {{ uniq_id }} value

{% for vlan in vlans|dictsort %}
Matched VLAN id {{ vlan[0]|string }} for {{ vlan[1].description }}
{% endfor %}

The result is:

Working dict 255 value

Matched VLAN id 2 working VLAN 2 on unique host 255
Matched VLAN id 4 for another example
Matched VLAN id {{ uniq_id }} for not working

The environment is ansible (1.6.3) & jinga2 (2.7.3), again it looks like substitution works fine for strings and values, but not array keys? Much appreciate any guidance on what could be happening here, thank you.

--Matt

Michael DeHaan

unread,
Jun 29, 2014, 5:04:57 PM6/29/14
to ansible...@googlegroups.com
Jinja2 is a templating system and Ansible has a variable system that allows Jinja2 evaluation of recursive value references, but we don't run it wholesale across the file, it's run on the keys.

Thus, you cannot have the name of a key in a dictionary in Ansible that is a variable, for instance.

(If this differed in value between different hosts, it wouldn't make any sense to the system, among other things)



--
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-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1a4823d3-b1d3-4d83-9f2c-0c3fc7a751e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Matt Peterson

unread,
Jun 29, 2014, 6:20:18 PM6/29/14
to ansible...@googlegroups.com
Right, I understand what Jinga2 is... Do you have an alternative approach? Thanks.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.

Michael DeHaan

unread,
Jun 30, 2014, 9:56:27 AM6/30/14
to ansible...@googlegroups.com

I don't have a solution for what you are trying to do with variable named keys, but let's step back and try to understand the use case you are trying to model and we can recommend a way to do that.

Can you talk about what you are deploying and configuring and why you think you may need the above idea?



To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/7a343ee3-3c5c-4ddd-a17c-2553b6c49151%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages