# looping over a role, revisited **URL:** \ **Category:** Ansible Project\ **Created:** [January 20, 2014, 1:42pm UTC](https://forum.ansible.com/t/looping-over-a-role-revisited/14384 "2014-01-20T13:42:18Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Nick](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@Nick](https://forum.ansible.com/u/Nick)\ **Post date:** [January 20, 2014, 1:42pm UTC](https://forum.ansible.com/t/looping-over-a-role-revisited/14384/1 "2014-01-20T13:42:18Z")
Hello, I wondered if this previously-posted hack to loop over roles still the best option out there? (i.e. Without the need to modify the role in question to unroll the loops at a task level, as advocated as a workaround otherwise.)    "Looping over roles ?" 5th Nov 2013 [https://groups.google.com/d/topic/ansible-project/3D81SEUoNuQ/discussion](https://groups.google.com/d/topic/ansible-project/3D81SEUoNuQ/discussion) Is there any plan afoot to implement something in core to do something equivalent in a nicer (and unbounded) way? I say this hopefully, in the belief that it would make role design easier and less error prone: you would only need to think about the simple case of one instance. Thanks, N ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [January 20, 2014, 1:47pm UTC](https://forum.ansible.com/t/looping-over-a-role-revisited/14384/2 "2014-01-20T13:47:21Z")
There’s no concept of looping over roles presently. If you mean passing a list to a role, that’s fine, and you can do that. There’s a fundamental reason this is done, in that the role must be applied in the same definition (but not the same variables) to each host in the host group. Ergo, you can’t have different numbers of roles applied to different hosts in the same group based on some kind of inventory variance. (So you should make a role that can take a list of input items, and then loop over it internally) ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [January 20, 2014, 1:48pm UTC](https://forum.ansible.com/t/looping-over-a-role-revisited/14384/3 "2014-01-20T13:48:00Z")
I should also add, the above is not a hack. It’s encouraged syntax 🙂 roles: - { role: setup\_users, users: “{{ my\_users }}” } etc ---
**Author:** ![Nick](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@Nick](https://forum.ansible.com/u/Nick)\ **Post date:** [January 20, 2014, 3:00pm UTC](https://forum.ansible.com/t/looping-over-a-role-revisited/14384/4 "2014-01-20T15:00:24Z")
> I should also add, the above is not a hack. > > It's encouraged syntax 🙂 > > roles: >   - { role: setup\_users, users: "{{ my\_users }}" } Possibly I didn't explain what I meant by the "hack" very well: I meant the one Jerome Wagner suggested which uses a 'loop' wrapper role with the capability to repeat another named role N times (up to some bound M), by supplying a list of N sets of parameters to pass. The role has M invocations of that role, each of which is guarded by a conditional which skips it unless there is a corresponding element in the list. To quote: > Let's say you have you role : "ruby\_install\_one\_version" > > Now you define a new role "loop" > - { role: "loop", over: "ruby\_install\_one\_version", iconf: [{ version: "1.9.3-p448"}, { version: "2.0.0-p247" }] } > > in meta.main.yml / dependency, you add something like (I still have a hard time with $ and {{}} in these contexts and I am not sure .length is the way to do it) > > - { role: "{{ over }}", conf: $iconf[0], when: "0 \< iconf.length" } > - { role: "{{ over }}", conf: $iconf[1], when: "1 \< iconf.length" } > - { role: "{{ over }}", conf: $iconf[2], when: "2 \< iconf.length" } > - { role: "{{ over }}", conf: $iconf[3], when: "3 \< iconf.length" } > - { role: "{{ over }}", conf: $iconf[4], when: "4 \< iconf.length" } Does Jerome's work-around fall foul of the limitation you mention? i.e. That: > ...the role must be applied in the same definition (but not the same variables) to each host in the host group. Ergo, you can't have different numbers of roles applied to different hosts in the same group based on some kind of inventory variance. If so, I'm curious to know in case I need to resort to this solution. I would suspect that there would be no problem, since the parameters are supplied directly to the role and not implicitly taken from the host\_vars/group\_vars, but perhaps I'm not understanding something. If not, couldn't there be an in-core Ansible solution which works essentially the same way (but without the upper bound)? Cheers, N ---
**Author:** ![Jerome\_Wagner](https://avatars.discourse-cdn.com/v4/letter/j/76d3ee/32.png) [@Jerome\_Wagner](https://forum.ansible.com/u/Jerome_Wagner)\ **Post date:** [January 20, 2014, 10:33pm UTC](https://forum.ansible.com/t/looping-over-a-role-revisited/14384/5 "2014-01-20T22:33:52Z")
> Hello Just to clarify if Michael you have time to look at this, the “hack” that resurfaces here was used by the person to whom I answered in this playbook : [https://github.com/leucos/ansible-rbenv-playbook/tree/master/roles](https://github.com/leucos/ansible-rbenv-playbook/tree/master/roles) you will see the “loop over roles” hack in the ruby-multi role. I’d be interested to know what you think about it for low-volume looping. Jerome ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [January 21, 2014, 12:03am UTC](https://forum.ansible.com/t/looping-over-a-role-revisited/14384/6 "2014-01-21T00:03:32Z")
Ah this: [https://github.com/leucos/ansible-rbenv-playbook/blob/master/roles/ruby-multi/meta/main.yml](https://github.com/leucos/ansible-rbenv-playbook/blob/master/roles/ruby-multi/meta/main.yml) Can’t say I’m a fan. I still think you’d rather pass the lists of things to instantiate into the “ruby” role and loop therein. yes, it’s going to start them all in parts, but it’s still going to achieve the final end result, and will be cleaner.