# transforming data from the inventory into role parameters

**URL:** <https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441>\
**Category:** Ansible Project\
**Created:** [January 28, 2014, 9:49am UTC](https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441 "2014-01-28T09:49:44Z")\
**Posts on this page:** 7\
**Page:** 1

<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:** [January 28, 2014, 9:49am UTC](https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441/1 "2014-01-28T09:49:44Z")

</div>

Hi,

When writing roles, I try and keep them re-usable. This means avoiding making them dependent on any arrangement of vars in my inventory and playbooks.

The problem I keep bumping into then is that ansible / jinja2 have limited means of transforming, for example, a list of server description hashes, into a hash of server name to ssh public keys.

I find myself pining for list comprehensions, so I could do this sort of thing:

```vars:` `# an example of a typical datastructure in the inventory:` `# details aren’t important, what matters is that it is not` `# 1:1 with the role’s requirements` `servers:` `- name: server1` `ssh:` `keys:` `rsa:` `pub: ‘xsdfjhdkfuhwef …’` `prv: ‘…’` `# …` `- name: server2` `ssh:` `# … and so on`

`# elsewhere...`  
`roles:`  
`# This role just wants a dictionary mapping server name -> rsa public key`  
```- role: foo` `server\_keys: `

…Where the list comprehension creates a map of item.name → item.ssh.keys.rsa.pub extracted from the ‘servers’ list.

How do other people approach this? Is there a good solution?

Thanks,

N

---

<div class="post-metadata">

**Author:** ![kahlil.hodgson](https://avatars.discourse-cdn.com/v4/letter/k/b9bd4f/32.png) [@kahlil.hodgson](https://forum.ansible.com/u/kahlil.hodgson)\
**Post date:** [January 28, 2014, 9:56pm UTC](https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441/2 "2014-01-28T21:56:37Z")

</div>

If your control node has Jinja2.7 you may be able to use the 'map'  
filter to emulate the desired comprehension  
See [http://jinja.pocoo.org/docs/templates/#builtin-filters](http://jinja.pocoo.org/docs/templates/#builtin-filters)

Kahlil (Kal) Hodgson GPG: C9A02289  
Head of Technology (m) +61 (0) 4 2573 0382  
DealMax Pty Ltd (w) +61 (0) 3 9008 5281

Suite 1415  
401 Docklands Drive  
Docklands VIC 3008 Australia

"All parts should go together without forcing. You must remember that  
the parts you are reassembling were disassembled by you. Therefore,  
if you can't get them together again, there must be a reason. By all  
means, do not use a hammer." -- IBM maintenance manual, 1925

---

<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:** [January 28, 2014, 10:35pm UTC](https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441/3 "2014-01-28T22:35:41Z")

</div>

Thanks, I did spot that in the documentation, but sadly, no I don't have the  
right version of jinja2 (on Ubuntu 12.04). I could try and upgrade, but I  
suspect that wouldn't be sensible.

Besides:

a) jinja2's map filter looks like it may only handle top-level attributes of  
list items  
b) the result would be a string and presumably would not be treated as a data  
structure by the consuming role

I'd be pleased to find out I'm wrong, of course.

N

---

<div class="post-metadata">

**Author:** ![kahlil.hodgson](https://avatars.discourse-cdn.com/v4/letter/k/b9bd4f/32.png) [@kahlil.hodgson](https://forum.ansible.com/u/kahlil.hodgson)\
**Post date:** [January 28, 2014, 11:22pm UTC](https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441/4 "2014-01-28T23:22:35Z")

</div>

Had a quick look at the source code for the map filter, and I believe  
it will descend to lower levels and the result is an arbitrary list,  
so I think this would work.

However, this is of no use if your control node is running a stable OS 🙂

The only other approach I can think of is to split out keys from the  
'servers' the data structure. Yes ugly ☹

K

Kahlil (Kal) Hodgson GPG: C9A02289  
Head of Technology (m) +61 (0) 4 2573 0382  
DealMax Pty Ltd (w) +61 (0) 3 9008 5281

Suite 1415  
401 Docklands Drive  
Docklands VIC 3008 Australia

"All parts should go together without forcing. You must remember that  
the parts you are reassembling were disassembled by you. Therefore,  
if you can't get them together again, there must be a reason. By all  
means, do not use a hammer." -- IBM maintenance manual, 1925

---

<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:** [January 29, 2014, 12:00am UTC](https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441/5 "2014-01-29T00:00:39Z")

</div>

Thanks again.

Mainly I'm wondering why no-one else is admitting to have run into this conundrum...

N

---

<div class="post-metadata">

**Author:** ![Damjan\_Georgievski](https://avatars.discourse-cdn.com/v4/letter/d/e19b73/32.png) [@Damjan\_Georgievski](https://forum.ansible.com/u/Damjan_Georgievski)\
**Post date:** [January 29, 2014, 12:13pm UTC](https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441/6 "2014-01-29T12:13:42Z")

</div>

Why not?  
Just run “pip install --user Jinja2” it’ll install it in ~/.local/lib/

---

<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:** [January 29, 2014, 2:10pm UTC](https://forum.ansible.com/t/transforming-data-from-the-inventory-into-role-parameters/14441/7 "2014-01-29T14:10:26Z")

</div>

Considered laziness. I’d like to avoid adding in dependencies which I then need to ensure are always present, when they aren’t proven to be worth the effort. Thanks, despite what I said above, that may come in useful at some point. N
