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 Proposal #21 <https://github.com/ansible/proposals/pull/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 reproduceable. 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 to ansible-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
