"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. On Fri, Dec 6, 2013 at 7:32 PM, Matt Cordial <[email protected]> wrote: > 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 > > -- > You received this message because you are subscribed to the Google Groups > "Ansible Project" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Michael DeHaan <[email protected]> CTO, AnsibleWorks, Inc. http://www.ansibleworks.com/ -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
