Clarification on 2.0 precedence

Archives Ansible Project
1

Howdy! I’m working out variable precedence (yeah, this seems to come up a lot lately). This time around, it seems there is a conflict in the docs (or in my understanding). http://docs.ansible.com/ansible/playbooks_variables.html says precedence in 2.0 is:

In 2.x we have made the order of precedence more specific (last listed wins):

  • role defaults [1]
  • inventory vars [2]
  • inventory group_vars
  • inventory host_vars
  • playbook group_vars
  • playbook host_vars
  • host facts
  • registered vars
  • set_facts
  • play vars
  • play vars_prompt
  • play vars_files
  • role and include vars
  • block vars (only for tasks in block)
  • task vars (only for the task)
  • extra vars
    Then, below that, the paragraph contains the statement:
    “”"
    Basically, anything that goes into “role defaults” (the defaults folder inside the role) is the most malleable and easily overridden. Anything in the vars directory of the role overrides previous versions of that variable in namespace. The idea here to follow is that the more explicit you get in scope, the more precedence it takes…
    “”"
    I don’t see that above. Why would variables in a role’s var directory take precedence over a playbook’s vars? You would use a role (say, network_config) across several playbooks (db server, web server, etc). I also don’t understand the inventory being “beaten” by playbook vars. If I have a playbook (say, app_server), I would use that across multiple inventories (like devel, staging, prod) and it seems I would want to have that override any group/host vars I had in the playbook.

Also why would a role’s defaults/main.yml be easily overridden, but a role’s vars/.yml be among the highest precedence? Wouldn’t a role’s vars/* also be default-ish type values?

I have seen blog posts where people have worked around this by doing devel/staging/production children groups, but that just seems like a work around for incorrect (or at least unintuitive) behavior.

Help? :slight_smile:

Thanks!

P.S. Before you yell at me and tell me to go RTFM, I have read the manual. First page to last. I’m just trying to fill in gaps in my understanding. If there is a portion of the manual I need to re-read, I’m cool with that. A design doc (or code comment) explaining rationale for the levels would be even better.

2

Totally agree there needs to be some explanation of how to do per-environment settings when the precedence works in this order.

That said, this works for us:

  • set role defaults with roles/rolename/defaults/main.yml
    (our internal convention says any tuneables for a role live there)
  • override in inventory as needed

For any vars that have no sane defaults, we document it in defaults/main.yml
and make sure any errors thrown point you there.

3

replying inline

I don't see that above.

Not sure what you are 'not seeing'.

Why would variables in a role's var directory take precedence over a playbook's vars?

The thought was that roles are more specific than plays and should
have control over their own vars, this ended up being a problem so
defaults were created to allow for easy override, which also answers
some of your followups.

P.S. Before you yell at me and tell me to go RTFM, I have read the manual.
First page to last. I'm just trying to fill in gaps in my understanding. If
there is a portion of the manual I need to re-read, I'm cool with that. A
design doc (or code comment) explaining rationale for the levels would be
even better.

There is no RTFM in this case as you are asking about why some
decisions were taken, not clarification on how it works.