# Idea: playing roles directly, implicit playbooks **URL:** \ **Category:** Ansible Project\ **Created:** [June 20, 2013, 1:36pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995 "2013-06-20T13:36:20Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![martin\_f\_krafft](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@martin\_f\_krafft](https://forum.ansible.com/u/martin_f_krafft)\ **Post date:** [June 20, 2013, 1:36pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/1 "2013-06-20T13:36:20Z")
Dear list, have you ever wanted to "play" a role directly and found yourself in the position that you needed to whip up a playbook with mostly derived contents just in order to do that? For instance, I have a 'motd' role that contains everything I need to construct /etc/motd files. I also have an inventory group 'motd\_hosts'… I would really love to be able to just say   ansible-playbook ~/ansible/roles/motd/ and be done with it. How would this work? If ansible-playbook gets passed a directory instead of a YAML-file, then it could assume that the directory was a role and construct a sensible playbook for it on the fly. It would have some sanity checks built in, obviously, to ensure that it is being fed a role directory. For instance, consider the following role:   roles/motd   ├── tasks   │ └── main.yml   ├── templates   │ └── motd.j2   └── vars       └── main.yml You would use this role with a playbook like this: ---
**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:** [June 20, 2013, 4:09pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/2 "2013-06-20T16:09:31Z")
The goal of ansible plays have always been, even before plays, that plays map sets of hosts to the behaviors (roles, if you will) that they perform. It’s not just one role, but many. A hosts can fulfill many different roles. One might be common, one might be “datacenter1”, one might be “security”, and one might be “webserver”. So, I don’t really think this needs to be a thing. ---
**Author:** ![martin\_f\_krafft](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@martin\_f\_krafft](https://forum.ansible.com/u/martin_f_krafft)\ **Post date:** [June 20, 2013, 5:12pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/3 "2013-06-20T17:12:02Z")
also sprach Michael DeHaan \ [2013.06.20.1809 +0200]: > The goal of ansible plays have always been, even before plays, that plays > map sets of hosts to the behaviors (roles, if you will) that they perform. What do you suggest to do in a case where a CMDB already contains all the information about which "roles" to apply? In the combined use cases that I have to manage, there will be several hundred roles, all with associated groups in the inventory. Is it really necessary to create a playbook for every role that just maps "role\_hosts" to "role"? Do you see a different way? Sure, this can be done in a very simple for-loop, but it's still redundant information written to disk and a source of error I'd like to avoid. What do others think? ---
**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:** [June 20, 2013, 8:39pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/4 "2013-06-20T20:39:21Z")
Well, sort of. You wouldn’t define playbooks for every role, you define playbooks for every group of host – important conceptual difference. In fact, you may have many DIFFERENT playbooks that target the same groups of hosts to do different things. I think the fundamental misunderstanding here is folks are coming in from tools like Puppet and not looking at the general process orchestration or app deployment use cases. You don’t just have to have the one site.yml that is like a site.pp (in which case I can see the idea of being able to assign roles from inventory), but rather as many as you want. It might be technically possible to define a set of roles to define in group\_vars – you would think – but it’s not. The reason being, suppose you included a role for every machine in ‘webservers’ and wanted to auto build the play. However, some webservers are in Boston and some are in DC. The Boston webservers need an additional role named ‘Boston’, and some in ‘DC’ need the DC role. Thus the play is THE place where you define that. I view the idea that you want to externalize that outside the playbook as an unneccessary abstraction, because the play IS the place where you define it. If you have different requirements, I have no problems with people code-generating the playbook (see what Jesse Keating is doing with ansibox), but I don’t see this needs to be a 1st class concept in Ansible. ---
**Author:** ![martin\_f\_krafft](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@martin\_f\_krafft](https://forum.ansible.com/u/martin_f_krafft)\ **Post date:** [June 21, 2013, 8:21am UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/5 "2013-06-21T08:21:02Z")
also sprach Michael DeHaan \ [2013.06.20.2239 +0200]: > I think the fundamental misunderstanding here is folks are coming > in from tools like Puppet and not looking at the general process > orchestration or app deployment use cases. Well, not all users of Ansible need process orchestration or app deployment. Our nodes are all independent of each other. > You don't just have to have the one site.yml that is like > a site.pp (in which case I can see the idea of being able to > assign roles from inventory), but rather as many as you want. Yes, this is indeed very nice, to be able to play just one book at a time. However, if you want to manage systems, you will want to have Ansible run regularly, to ensure that local changes that are not in-line with your infrastructure definition (inventory, whatever), get reverted. And at this point you need site.yml or master.yml. I also understand your point about playbooks targetting groups of hosts. But what about the case when a group already corresponds to a role? > The reason being, suppose you included a role for every machine in > 'webservers' and wanted to auto build the play. > > However, some webservers are in Boston and some are in DC. The > Boston webservers need an additional role named 'Boston', and some > in 'DC' need the DC role. Yes, of course. Those additional roles get applied too. After the 'webserver' role was applied to all 'webserver\_hosts', the 'Boston' role gets applied to all nodes in the group 'hosted@boston\_hosts' (our naming convention). You can either manage this with group\_vars, as you suggest, or with groups, which is what we do. I.e. there is a group for every role already present. > Thus the play is THE place where you define that. > > I view the idea that you want to externalize that outside the > playbook as an unneccessary abstraction, because the play IS the > place where you define it. … unless you already have the information elsewhere. Am I reading you right that you won't consider this use case, that you suggest I auto-generate playbooks on my end to cater for my needs, but that you won't consider whatever I come up with for core inclusion? Cheers, ---
**Author:** ![Serge\_van\_Ginderacht](https://avatars.discourse-cdn.com/v4/letter/s/b782af/32.png) [@Serge\_van\_Ginderacht](https://forum.ansible.com/u/Serge_van_Ginderacht)\ **Post date:** [June 21, 2013, 8:45am UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/6 "2013-06-21T08:45:32Z")
​Martin, Instead of autogenerating playbooks, you could consider​ tweaking ansible-playbook into "ansible-role", which could be a tool holding the middle between ansible and ansible-playbook: running a bunch of tasks on hosts, instead of just one module. I could see a use for such a tool. Whether that is stuff for core, doesn't really matter, as it's just a separate script. Serge ---
**Author:** ![martin\_f\_krafft](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@martin\_f\_krafft](https://forum.ansible.com/u/martin_f_krafft)\ **Post date:** [June 21, 2013, 9:45am UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/7 "2013-06-21T09:45:40Z")
also sprach Serge van Ginderachter \ [2013.06.21.1045 +0200]: > Instead of autogenerating playbooks, you could consider tweaking > ansible-playbook into "ansible-role", Yeah, I considered this and it's still on my list of possible avenues. > I could see a use for such a tool. Whether that is stuff for core, > doesn't really matter, as it's just a separate script. True, but I am always trying to find solutions that keep my "diff" from upstream as small as possible, because when Ansible 2.0 comes out, I don't want to find myself relying on an API that is no longer supported. Or somesuch. You get the idea. Furthermore, I think that while the philosophy of Ansible is worth being looked at and considered from a step back, there is no reason to force users to do it that way only, really. Isn't Free software about choice? Not only between tools, but also in tool functionality? Now, I am not talking about modifying core in any way that affects existing behaviour, or introduces complexity. I am talking about introducing a new way to approach things, which some will find useful and others will not. That's the choice I am talking about. Doesn't Ansible as a whole gain from this? ---
**Author:** ![Brian\_Coca1](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Brian\_Coca1](https://forum.ansible.com/u/Brian_Coca1)\ **Post date:** [June 21, 2013, 12:39pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/8 "2013-06-21T12:39:14Z")
@martin, In your case it seems you don’t need roles and can just use playbooks that overlap with your current existing role setup. ---
**Author:** ![GW1](https://avatars.discourse-cdn.com/v4/letter/g/c89c15/32.png) [@GW1](https://forum.ansible.com/u/GW1)\ **Post date:** [June 21, 2013, 12:51pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/9 "2013-06-21T12:51:07Z")
Or looking from a different perspective, parameterized roles are pretty similar to modules for the end user, so they could both be executable from `ansible`, eg. `ansible webservers -r uwsgi -a "workers=10"` (-r for roles, -m for modules). Greetings, gw ---
**Author:** ![martin\_f\_krafft](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@martin\_f\_krafft](https://forum.ansible.com/u/martin_f_krafft)\ **Post date:** [June 21, 2013, 1:15pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/10 "2013-06-21T13:15:27Z")
also sprach Brian Coca \ [2013.06.21.1439 +0200]: > In your case it seems you don't need roles and can just use > playbooks that overlap with your current existing role setup. That is true, except I liked having templates in ./templates/ next to the playbook. But I suppose that is not necessary, actually. Thanks for the whack with the cluebat. ---
**Author:** ![martin\_f\_krafft](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@martin\_f\_krafft](https://forum.ansible.com/u/martin_f_krafft)\ **Post date:** [June 21, 2013, 1:25pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/11 "2013-06-21T13:25:04Z")
also sprach GW \ [2013.06.21.1451 +0200]: > Or looking from a different perspective, parameterized roles are > pretty similar to modules for the end user, so they could both be > executable from `ansible`, eg. `ansible webservers -r uwsgi -a > "workers=10"` (-r for roles, -m for modules). I can't find it anymore, but Michael said that roles are like Puppet defines, i.e. wrappers around tasks and related files, parametrised and reusable in that sense. Do you have an example of what you consider to be an excellent application of the roles concept? ---
**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:** [June 22, 2013, 5:36pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/12 "2013-06-22T17:36:29Z")
While not parameterized, there are many roles examples in [https://github.com/ansible/ansible-examples/tree/master/lamp\_simple](https://github.com/ansible/ansible-examples/tree/master/lamp_simple) (for instance, the lamp\_simple example) ---
**Author:** ![martin\_f\_krafft](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@martin\_f\_krafft](https://forum.ansible.com/u/martin_f_krafft)\ **Post date:** [June 22, 2013, 5:55pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/13 "2013-06-22T17:55:01Z")
also sprach Michael DeHaan \ [2013.06.22.1936 +0200]: > While not parameterized, there are many roles examples in > [https://github.com/ansible/ansible-examples/tree/master/lamp\_simple](https://github.com/ansible/ansible-examples/tree/master/lamp_simple) (for > instance, the lamp\_simple example) I note that that playbook does not much more than map group names to role names:   all → common   dbservers → db   webservers → web When you look at that playbook, don't you have an itch to remove this redundancy, this extra layer, which doesn't add anything? I know playbooks can add a lot. I am not proposing to change that. I am proposing to find a way to eliminate them only in use-cases when the group names map directly to role names… ---
**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:** [June 22, 2013, 6:13pm UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/14 "2013-06-22T18:13:41Z")
It adds a heck of a lot, as you may also want to apply additional roles in that same mapping, may later add load balancing (pre\_tasks, post\_tasks) and so on. You can also do free form tasks, group\_by operations to create dynamic groups, etc. If someone is using ansible for a small subset of what it can do, I think, is not reason to create a method of operation that allows it to do only that subset. Again, minimal system – less tools – less keywords. This is not duplication, this is the exact place where you define the mapping for this particular playbook run. Another playbook may do something totally different with those groups of hosts. ---
**Author:** ![martin\_f\_krafft](https://avatars.discourse-cdn.com/v4/letter/m/8797f3/32.png) [@martin\_f\_krafft](https://forum.ansible.com/u/martin_f_krafft)\ **Post date:** [June 23, 2013, 8:10am UTC](https://forum.ansible.com/t/idea-playing-roles-directly-implicit-playbooks/12995/15 "2013-06-23T08:10:06Z")
also sprach Michael DeHaan \ [2013.06.22.2013 +0200]: > It adds a heck of a lot, as you may also want to apply additional roles in > that same mapping, may later add load balancing (pre\_tasks, post\_tasks) and > so on. You can also do free form tasks, group\_by operations to > create dynamic groups, etc. My initial suggestion lets you do all of that, because when Ansible would be told to "play a role", then it would augment its implicit assumptions (which hosts to map a role to) from a playbook. My proposal adds to Ansible: if all you need is to apply role 'foo' to ''foo\_hosts' and role 'bar' to 'bar\_hosts', like in the example you showed me when I asked about "typical role usage", then I am offering a shortcut. If that shortcut doesn't do everything you want, then you don't have to use it.