Yep, roles that just cary variables in "/roles/foo/vars/main.yml" can be a
perfect solution for cases like this, just include them before your other
role.

Basically a role describes what something is, but they don't entirely have
to self contained.

Ansible contains some nice protections to make sure if you reference a var
*IN* a role you'll get that variable, no surprises, but roles can define
variables for other roles.




On Wed, Aug 27, 2014 at 3:51 PM, John Dickerson <[email protected]>
wrote:

> In our environment, we have several roles that share common default "site"
> variables for things like the lists of domain controllers, NTP servers, the
> name of the kerberos realm, etc.  Many of these variables are used in more
> than one role, but not all the roles are used by all systems.  So we just
> created a role called "site-defaults" that only has a defaults/main.yml
> containing all the site-specific default variables; it doesn't perform any
> tasks.  Then we just add a role dependency in the other roles for the
> site-defaults role.  Admins can always override the defaults with host or
> group variables if they need to, but at least we make an attempt to get
> everyone off on the right foot.
>
> On Wednesday, August 27, 2014 2:11:55 PM UTC-5, Michael DeHaan wrote:
>
>> Setting defaults in group_vars/all is usually a very good place to set
>> global defaults.
>>
>> Note that role defaults are a lower priority than inventory though.
>>
>> You could also consider symlinks.
>>
>>
>>
>>
>> On Wed, Aug 27, 2014 at 12:59 PM, Daniele Varrazzo <[email protected]
>> > wrote:
>>
>>> Hello, first of all thank you very much for Ansible.
>>>
>>> I'm setting up the deployment of a complex system and splitting it
>>> across roles. I haven't found yet a satisfactory way of sharing variables
>>> across the roles. A simple example: set the database port in the db role
>>> and use it in the web role. I'm expecting to be able do do something along
>>> this line:
>>>
>>>     roles/
>>>         db/
>>>             defaults/main.yml
>>>                 db_port: 5432
>>>         web/
>>>             templates/
>>>                  web.conf.j2
>>>                     [database]
>>>                     port: {{ db_port }}
>>>
>>> The above wants to represent the fact that the default port for the
>>> database is 5432; this may be overridden by a group_vars file for specific
>>> installation having the db on a non-standard port. Currently it doesn't
>>> work because the db_port variable is not known by the web role. How to work
>>> around that?
>>>
>>> 1. put all the shared variables in group_vars/all. It works but it
>>> breaks the encapsulation of the roles: without a certain unknown set of
>>> variables defined at least in "all" the db cannot be configured.
>>> 2. add the db role as a dependency of web: this makes it execute the
>>> entire db tasks list, which is not what hoped.
>>> 3. add "include_vars: ../../db/defaults/main.yml" to the web's tasks.
>>> This gives a higher preference to the default variable and overriding it in
>>> group_vars (or in the inventory) doesn't work anymore.
>>>
>>> As it is now I'm stuck with 1, which is also what I've generally found
>>> in the examples. Is there anything better? It seems a relatively
>>> straightforward use case to me:
>>>
>>> 1. a provider role defines a variable and provides a default for it;
>>> 2. a consumer role uses the variable provided;
>>> 3. a group or inventory variable can override the default.
>>>
>>> Thank you very much,
>>>
>>> -- Daniele
>>>
>>> --
>>> 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].
>>> To post to this group, send email to [email protected].
>>>
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/ansible-project/7762fbc1-5491-4f77-8db3-
>>> 0581af9bbf1e%40googlegroups.com
>>> <https://groups.google.com/d/msgid/ansible-project/7762fbc1-5491-4f77-8db3-0581af9bbf1e%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> 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].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/d6f74176-32e7-46e5-984a-644e6d3ae9f4%40googlegroups.com
> <https://groups.google.com/d/msgid/ansible-project/d6f74176-32e7-46e5-984a-644e6d3ae9f4%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgw362m_12QNqb32eC05BNpGzEzMFdLoeDz6DLeXNz6yxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to