I found this post (
http://stackoverflow.com/questions/29276198/ansible-how-to-construct-a-variable-from-another-variable-and-then-fetch-its-v) and was hoping to find a way to cope with it.
To sum up though, basically I have a situation where I'd like to get the value of a value of a variable.
e.g.:
defaults/main.yml:
---
Ubuntu:
14:
packages:
install:
- iptables
remove:
- mlocate
CentOS:
6:
packages:
install:
- emacs
remove: [ ]
packages:
install: "{{ ansible_distribution }}.{{ ansible_distribution_major_version }}.packages.remove|default([ ]) | union(my_packages.remove|default([ ]))"
remove: "{{ ansible_distribution }}.{{ ansible_distribution_major_version }}.packages.remove|default([ ]) | union(my_packages.remove|default([ ]))"
However, this is assigning a string value to packages.install and packages.remove not the actual list, so I have to force variable expansion. This works for tasks:
tasks/main.yml:
---
- name: install packages
action: "{{anisble_pkg_mgr }} state=present name={{ item }}"
with_items: "{{ packages.install }}"
But it does not work for templating:
templates/test.j2:
---
{{ packages.install }}
...
TASK: [template src=t.yml dest=/tmp/] *****************************************
--- before: /tmp/t.yml
+++ after: /home/ansible-playbooks/t.yml
@@ -0,0 +1,43 @@
+Ubuntu.14.packages.install
If I could force or enable multiple pass variable expansion on the definition of packages.install (i.e. expand {{ ansible_distribution }} and {{ ansible_distribution_major_version }} and then get the value of "Ubuntu.14.packages.install" and assign that list to packages.install ), I wouldn't need to force the expansion on the task and could also use the resulting list in templates like normal.
There are only two ways of getting around this as I see it, but neither are ideal. I could make tasks use a distribution specific when clause, but those are a pain as it ends up with a lot of duplicated work. I could also make distribution specific vars files and have an include_vars task, but this is bad as include_vars would prevent variables from being overridden in playbooks that used this role as a dependency.
Is this possible? Or does someone have a suggestion about how to cope with this situation that I haven't considered?