# Accessing role vars in plays that don't include the role (i.e. run the roles's tasks) **URL:** \ **Category:** Ansible Project\ **Created:** [December 7, 2013, 12:32am UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095 "2013-12-07T00:32:33Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Matt\_Cordial](https://avatars.discourse-cdn.com/v4/letter/m/9e8a1a/32.png) [@Matt\_Cordial](https://forum.ansible.com/u/Matt_Cordial)\ **Post date:** [December 7, 2013, 12:32am UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095/1 "2013-12-07T00:32:33Z")
Say I want to put basic config variables in roles/\*/vars/main.yml for use when the role’s tasks run, but also want to access them in a play that doesn’t include that role. A specific example of what I am talking about would be where I need to build a configuration file for an application that is configured in a subsequent play. Say I have a postgres role where the database port is defined in roles/postgres/vars/main.yml. In the next play I want to configure my web-application’s settings file with the database port. I know I could: 1. put all vars in group\_vars/all 2. include roles/postgres/vars/main.yml (or roles/postgres/defaults/main.yml?) in the vars\_files section of the play building the configuration file The first doesn’t seem ideal as pretty much all of my variables are needed in multiple plays therefore this file is getting really long. Plus it seems like it undermines the reusable nature of roles a bit. The second seems fine, except that I’m going to end up including _a lot_ of role-specific vars/main.yml (defaults/main.yml?) files on some plays. Plus I fear that I might be opening myself up to precedence problems. E.g. a variable is overridden in the previous play and isn’t reflected when including the role specific vars/defaults. My question is, are these my only options? Is there a better way to go about managing role related variables that are needed outside of the role? Thanks in advance for any advice, Matt ---
**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:** [December 7, 2013, 7:22pm UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095/2 "2013-12-07T19:22:16Z")
“Say I want to put basic config variables in roles/\*/vars/main.yml for use when the role’s tasks run, but also want to access them in a play that doesn’t include that role” Assuming you are already running 1.4, and you should be, since it’s released (just waiting on EPEL to roll over). you can do this from any task file: - include\_vars: …/roles/foo/vars/main.yml Though it seems like it might be better to just have the role depend on a common role, and set the variables there. ---
**Author:** ![Matt\_Cordial](https://avatars.discourse-cdn.com/v4/letter/m/9e8a1a/32.png) [@Matt\_Cordial](https://forum.ansible.com/u/Matt_Cordial)\ **Post date:** [December 8, 2013, 8:55pm UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095/3 "2013-12-08T20:55:37Z")
> - include\_vars: …/roles/foo/vars/main.yml Thanks Michael, I’ve considered this. Is there a benefit to using include\_vars over specifying the path in the vars\_files list? > Though it seems like it might be better to just have the role depend on a common role, and set the variables there. In my case I’m keeping “provisioning” and “deploy” as separate playbooks. So installing/configuring the base services (like postgres) happens before my app is configured with their settings. I don’t want to run all of the install/configure steps on those services every time I go to deploy. Thanks again, Matt ---
**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:** [December 8, 2013, 8:58pm UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095/4 "2013-12-08T20:58:17Z")
The only reason I wouldn’t use vars\_files is because vars\_files is a keyword at play level, so you can’t make it part of the role. If it’s a common file of variables though, the cleanest way is to just include the file as a role, and those variables will be made available to other roles. ---
**Author:** ![Matt\_Cordial](https://avatars.discourse-cdn.com/v4/letter/m/9e8a1a/32.png) [@Matt\_Cordial](https://forum.ansible.com/u/Matt_Cordial)\ **Post date:** [December 9, 2013, 12:44am UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095/5 "2013-12-09T00:44:48Z")
> The only reason I wouldn’t use vars\_files is because vars\_files is a keyword at play level, so you can’t make it part of the role. Oh, yeah, of course. I see. > If it’s a common file of variables though, the cleanest way is to just include the file as a role, and those variables will be made available to other roles. I’ll give this a shot. ---
**Author:** ![Yves\_Dorfsman](https://avatars.discourse-cdn.com/v4/letter/y/9de0a6/32.png) [@Yves\_Dorfsman](https://forum.ansible.com/u/Yves_Dorfsman)\ **Post date:** [December 20, 2013, 3:07pm UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095/6 "2013-12-20T15:07:11Z")
Another way of doing this is to use the dictionary ability of yaml, instead of adding them in the role, add them to group\_vars/all.yaml in a dictornary:      mysoftware:        license\_key: 12345        version: 2.0 ---
**Author:** ![John\_Dewey](https://avatars.discourse-cdn.com/v4/letter/j/b9bd4f/32.png) [@John\_Dewey](https://forum.ansible.com/u/John_Dewey)\ **Post date:** [December 21, 2013, 7:37am UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095/7 "2013-12-21T07:37:17Z")
> > Say I want to put basic config variables in roles/\*/vars/main.yml for use when > > the role’s tasks run, but also want to access them in a play that doesn’t > > include that role. A specific example of what I am talking about would be > > where I need to build a configuration file for an application that is > > configured in a subsequent play. > > Another way of doing this is to use the dictionary ability of yaml, instead of > adding them in the role, add them to group\_vars/all.yaml in a dictornary: > > mysoftware: > license\_key: 12345 > version: 2.0 Yes, but this doesn’t seem ideal. Especially with the release of galaxy. IMO if we are using galaxy as a means to share code. The roles we share should include vars that can (defaults/main.yml) and cannot (vars/main.yml) be overridden. IMO, if the memcached role defines a port or path, that port should be available to the entire system. ---
**Author:** ![Garron\_Moore](https://avatars.discourse-cdn.com/v4/letter/g/3be4f8/32.png) [@Garron\_Moore](https://forum.ansible.com/u/Garron_Moore)\ **Post date:** [December 30, 2013, 10:38pm UTC](https://forum.ansible.com/t/accessing-role-vars-in-plays-that-dont-include-the-role-i-e-run-the-roless-tasks/14095/8 "2013-12-30T22:38:47Z")
I have a similar need to re-use variables related to a role without running the tasks associated with that role. At this point, I’m putting them all in group\_vars/all, but it’s getting a bit challenging to manage. With the include\_vars approach, would we lose the ability to override them in group\_vars and host\_vars? Before settling on group\_vars/all, my previous approach was to not have a main.yml and to include a tasks file from the role explicitly in my playbook, although with this approach I lost the ability to see which role was currently being executed and it felt kind of clunky (so I abandoned it). I think a really slick interface to address this workflow would be to allow specifying specific task files for a role in the roles declaration. Something like: roles: some\_role:some\_tasks In that example, some\_tasks would be referring to roles/some\_role/tasks/some\_tasks.yml. This would accommodate re-using role variables by simply not having a tasks/main.yml and explictly specifying the task list in the playbooks that need them. With that setup, my random auxillary playbooks would all have “roles: [my\_app]”, while my main deployment playbook would have “roles: [my\_app:deploy]”.