# "Cumulative" vars **URL:** \ **Category:** Ansible Project\ **Created:** [April 25, 2012, 7:46pm UTC](https://forum.ansible.com/t/cumulative-vars/11446 "2012-04-25T19:46:45Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Michel\_Blanc1](https://avatars.discourse-cdn.com/v4/letter/m/fbc32d/32.png) [@Michel\_Blanc1](https://forum.ansible.com/u/Michel_Blanc1)\ **Post date:** [April 25, 2012, 7:46pm UTC](https://forum.ansible.com/t/cumulative-vars/11446/1 "2012-04-25T19:46:45Z")
Dear all, Currently, it is possible to have compount vars, where, for instance, a var contains an array like this : - group: base   hosts:   - all   vars:     somme\_array\_var:       - "foo"       - "bar" However, it is not possible to aggregate, or more specifically, push more values in those arrays. Redefining 'somme\_array\_var' elsewhere would overwrite the previously defined value (which one overwrites the other is another story, there's an issue on this [https://github.com/ansible/ansible.github.com/issues/73](https://github.com/ansible/ansible.github.com/issues/73)). Such a feature, that would allow one to accumulate values in an array, populated in hosts, groups, etc.. would be quite useful IMHO. Here is a real-world scenario : Let's say you want to generate your firewall rules dynamically. As a baseline, all hosts have port 22/tcp inbound open. However, your nameservers will want to open 53/udp and 53/tcp, your ntp servers 123/udp, etc.... (I'm restricting myself to inbound connections, to try to keep things understandable). We then could use a template like this : ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [April 26, 2012, 12:13pm UTC](https://forum.ansible.com/t/cumulative-vars/11446/2 "2012-04-26T12:13:15Z")
This was one of the points on the YAML inventory thread, though I agree it’s not just a YAML inventory thing. I think you’re trying too hard to replicate a common pattern of doing it in Puppet and so forth, and if we have to think in terms of array concatenation, we have made Ansible too complicated. I would probably recommend just maintaining a template for firewall rules and having conditionals in the template, and depending on whether the template variables were set, certain parts would come into play or not. For example “needs\_snmp” could gate an allow section for SNMP. { % if needs\_snmp is defined %} blah { %endif } {% if needs\_foo is defined % } {% endif } Etc. One of the things I _try_ to stress is that the goal of Ansible is to make configurations audit able. Having one master template for all of your firewall rules and seeing EXACTLY what is in that template, and being able to rapidly edit it is one of those things. I agree we need more examples like this. If someone wants to write something like a firewall rules playbook example, that would be pretty awesome. I want to start thinking about assembling the contrib repo again, this time to encourage people to go fast, it will probably use git submodules to link to good ansible content all over the github. I know I have some and Seth does, etc, but we should be sharing how we do things more so we can talk about them more in context. Let’s make it happen. –Michael ---
**Author:** ![Michel\_Blanc1](https://avatars.discourse-cdn.com/v4/letter/m/fbc32d/32.png) [@Michel\_Blanc1](https://forum.ansible.com/u/Michel_Blanc1)\ **Post date:** [April 26, 2012, 12:23pm UTC](https://forum.ansible.com/t/cumulative-vars/11446/3 "2012-04-26T12:23:34Z")
> This was one of the points on the YAML inventory thread, though I agree > it's not just a YAML inventory thing. > > I think you're trying too hard to replicate a common pattern of doing it > in Puppet and so forth, and if we have to think in terms of array > concatenation, we have made Ansible too complicated. Indeed, you're right on this. > I would probably recommend just maintaining a template for firewall > rules and having conditionals in the template, and depending on whether > the template variables were set, certain parts would come into play or not. > > For example "needs\_snmp" could gate an allow section for SNMP. > > { % if needs\_snmp is defined %} >    blah > { %endif } > {% if needs\_foo is defined % } > {% endif } Thats an idea. > Etc. > > One of the things I \*try\* to stress is that the goal of Ansible is to > make configurations audit able. I ended up defining \*every\* needed port for \*every\* host. While not very not "DRY", this approach makes it much clearer since each host is self-explanatory in what port will be opened, and you don't have to make mental array pushes to understand what's being done. > If someone wants to write something like a firewall rules playbook > example, that would be pretty awesome. Mine is almost ready. Wilco. Thanks, M