Thanks for your input, even though I don't fully agree.

register vars / set_facts: If some "default" configuration options are e.g. 
gathered by shell commands and registered as variables with set_fact, this 
can by easily solved by just adding *when: var is not defined* to the 
particular task(s). For include_vars this is not an option because you have 
usually much more vars here and would have to put every variable into the 
when statement as well.

vars_prompt: I don't think that it's a use case to overwrite those 
variables within the inventory, as the options provided via CLI should 
always take precedence.

vars_files / inline_vars: As you already wrote, those can be easily 
prevented by using defaults/main.yml instead.

Meanwhile, include_vars usage cannot be easily prevented as you really need 
e.g. to write roles with multi-platform support (as already discussed in 
#21 <>).

I think extra_vars is not a realistic option for configuring everything, as 
in big projects people have to overwrite many variables and they also want 
to store their configuration within files to keep the ansible runs 

Am Donnerstag, 12. April 2018 20:34:53 UTC+2 schrieb Brian Coca:
> You would still have issues with set_fact, vars:, vars_prompt, 
> register, vars_files and inline vars to include and roles, as 
> inventory is not very high in the precedence. 
> One way to avoid this is to have client provide extra vars, which has 
> highest precedence, instead of inventory. 
> Another way is you provide your vars in a role as defaults/main.yml, 
> which has the lowest precedence, instead of include_vars. 
> -- 
> ---------- 
> Brian Coca 

You received this message because you are subscribed to the Google Groups 
"Ansible Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to