# Proposal: include\_defaults **URL:** \ **Category:** Ansible Project\ **Created:** [August 28, 2014, 8:48pm UTC](https://forum.ansible.com/t/proposal-include-defaults/16066 "2014-08-28T20:48:55Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Daniele\_Varrazzo](https://avatars.discourse-cdn.com/v4/letter/d/e19b73/32.png) [@Daniele\_Varrazzo](https://forum.ansible.com/u/Daniele_Varrazzo)\ **Post date:** [August 28, 2014, 8:48pm UTC](https://forum.ansible.com/t/proposal-include-defaults/16066/1 "2014-08-28T20:48:55Z")
Hello, after yesterday’s thread I’ve goggled a bit more around ansible and variables and I’ve figured out the following facts (of which many of you are probably aware but I’m new of the environment): - the precedence of the variables is set in stone: a lot of people rely on that and tweaking it is out of discussion; - several people using ansible are baffled by the inability to override from the inventory the variables set by a role (I’ve googled several articles discussing about the topic). My proposal is to add an include\_defaults with the same behaviour of include\_vars but whose values can be overridden using the usual mechanism. The rationale has been explained yesterday: it is not uncommon to have dependencies across roles. If role B depends on role A it cannot use values for variables provided by A unless these values are specified globally, e.g. in group\_vars/all. This breaks roles encapsulation and forces the maintenance of larger-than-necessary group\_vars files. Using include\_defaults only B is exposed to the variables whose default is provided by A and group\_vars files only need to override the more generic values provided by the role as fallback. I think my proposal is simple and doesn’t change radically the way ansible works (e.g. introducing a new level of vars precedence) and totally backward-compatible as it uses a new command. Reading the commentary about the topic I think it is a model many people expect and some users have developed their own hacks to work around the limitation (e.g. using no-tasks dependencies). The feature is implemented in my branch [https://github.com/dvarrazzo/ansible/tree/include\_defaults](https://github.com/dvarrazzo/ansible/tree/include_defaults) and consists of just a new plugin, no change to the tasks runner. It may be missing something or could be designed in a different way (e.g. it could be a “include\_vars target=default” instead of a new command, or it could take “role=name” instead of a full path to automatically include role/defaults/main.yml): feedback is welcome. I’m happy to know what other users and above all the developers think about the feature. Again, thank you very much for the invaluable tool you have provided. – Daniele ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 28, 2014, 8:56pm UTC](https://forum.ansible.com/t/proposal-include-defaults/16066/2 "2014-08-28T20:56:58Z")
“If role B depends on role A it cannot use values for variables provided by A unless these values are specified globally, e.g. in group\_vars/all.” Role variables in the “vars/” directory of a role are actually pulled into all roles. “- several people using ansible are baffled by the inability to override from the inventory the variables set by a role” We’ve explained this many times when folks have precedence questions. Many things have greater precedence than inventory variables, including role parameters and variables in the roles. Defaults are actually lower precedence. Again, I’d prefer to work back form the use case of what you are trying to model to see if things can’t be solved by existing systems, continuing to add more syntax increases the cognitive load of the program, which is something I like to resist 🙂 ---
**Author:** ![Tomasz\_Kontusz](https://avatars.discourse-cdn.com/v4/letter/t/bc79bd/32.png) [@Tomasz\_Kontusz](https://forum.ansible.com/u/Tomasz_Kontusz)\ **Post date:** [August 29, 2014, 6:36am UTC](https://forum.ansible.com/t/proposal-include-defaults/16066/3 "2014-08-29T06:36:01Z")
Michael DeHaan \ napisał: > "If role B depends on role A it cannot use values for variables > provided by > A unless these values are specified globally, e.g. in group\_vars/all." > > Role variables in the "vars/" directory of a role are actually pulled > into > all roles. I think the proposed include\_defaults task would be useful because of this - it would add an easy way for providing OS-specific defaults without cobbling other roles namespace. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 29, 2014, 11:47am UTC](https://forum.ansible.com/t/proposal-include-defaults/16066/4 "2014-08-29T11:47:01Z")
I haven’t seen the need for this pattern arise much, and my comments on this still hold. This can still be handled by this pattern: # assume the following defines a variable role\_var\_default - include\_vars: “{{ ansible\_os\_family }}.yml” - set\_fact: role\_var: “{{ role\_var | default(role\_var\_default) }}” If you need that functionality. “without cobbling other roles namespace.” Roles are already namespace protected so accidental namespace collisions are not possible. ---
**Author:** ![Daniele\_Varrazzo](https://avatars.discourse-cdn.com/v4/letter/d/e19b73/32.png) [@Daniele\_Varrazzo](https://forum.ansible.com/u/Daniele_Varrazzo)\ **Post date:** [August 29, 2014, 7:06pm UTC](https://forum.ansible.com/t/proposal-include-defaults/16066/5 "2014-08-29T19:06:45Z")
I’ve found yesterday that ansible gives the flexibility to add plugins outside its codebase. This is great as I (or anybody else) can keep on experimenting with import\_defaults without bothering the main codebase. I’ve uploaded include\_defaults to a gist: [https://gist.github.com/dvarrazzo/7418a89b7278ff69267c](https://gist.github.com/dvarrazzo/7418a89b7278ff69267c). Info about how to use it are there too. It still takes a file name as input but I think it would be better if it allowed ‘role=NAME’ too as option to get the role’s default file; I haven’t dug enough into ansible internals yet to find how to deal with the roles path resolution (of course if someone knows better patches are welcome). If anybody has found the same limitations I found and wants to give it a go it would be nice to know his comments. This may end up showing the emergence of a use case, in which case ansible developers will make their own choices, or not showing anything at all 🙂 In the meantime it’s nice to see the solution can live in just a few people’s playbook directories and doesn’t need hacking into ansible code. Thank you everybody, have a nice weekend. – Daniele ---
**Author:** ![Thomas\_Steinbach](https://avatars.discourse-cdn.com/v4/letter/t/df788c/32.png) [@Thomas\_Steinbach](https://forum.ansible.com/u/Thomas_Steinbach)\ **Post date:** [November 1, 2015, 2:54am UTC](https://forum.ansible.com/t/proposal-include-defaults/16066/6 "2015-11-01T02:54:07Z")
Oh I would like to see load\_defaults in the core of Ansible. I created some roles, which distinguishes between client and server installation. Depending on the installation type they should load different defaults (e.g. refresh rates, max. log size, …). I tried ‘load\_vars’, but it has a higher precedence and my playbook variables wouldn’t override them as the should do with ‘load\_defaults’. I hope you plugin will do the trick. Thanx in advance Thomas