ansible/community.general
1
0
Fork 0
mirror of https://github.com/ansible-collections/community.general.git synced 2024-09-14 20:13:21 +02:00
Code Releases Activity

Improve clarity of precedence when command-line parameters are used. (#39059)

Browse source 
* Improve clarity of precedence when command-line parameters are used.

* Add command-line values into the precedence list.
* Several sample config snippets were included without any explanation
  of how those snippets would be processed. Added descriptions so that
  the reader can understand what each snippet will (or won't) accomplish.

* Don't focus on inventory as much

Expand on the fact that it's the fact that a variable is set that
matters, not the source of the variable.
This commit is contained in:
James Polley 2018-08-31 23:56:58 +10:00 committed by Sandra McCann
parent cccf5e6e77
commit 7988266bb7
1 changed files with 14 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
docs/docsite/rst/user_guide/playbooks_variables.rst
View file

@ -828,6 +828,7 @@ If multiple variables of the same name are defined in different places, they get
Here is the order of precedence from least to greatest (the last listed variables winning prioritization): Here is the order of precedence from least to greatest (the last listed variables winning prioritization):
* command line values (eg "-u user")
* role defaults [1]_ * role defaults [1]_
* inventory file or script group vars [2]_ * inventory file or script group vars [2]_
* inventory group_vars/all [3]_ * inventory group_vars/all [3]_
@ -869,22 +870,29 @@ Basically, anything that goes into "role defaults" (the defaults folder inside t
This variable, ``ansible_group_priority``, can only be set in the inventory source and not in group_vars/ as the variable is used in the loading of group_vars/. This variable, ``ansible_group_priority``, can only be set in the inventory source and not in group_vars/ as the variable is used in the loading of group_vars/.
Another important thing to consider (for all versions) is that connection variables override config, command line and play/role/task specific options and keywords. For example:: Another important thing to consider (for all versions) is that connection variables override config, command line and play/role/task specific options and keywords. For example, if your inventory specifies `ansible_ssh_user: ramon` and you run::
ansible -u lola myhost ansible -u lola myhost
This will still connect as ``ramon`` because ``ansible_ssh_user`` is set to ``ramon`` in inventory for myhost. This will still connect as ``ramon`` because the value from the variable takes priority (in this case, the variable came from the inventory, but the same would be true no matter where the variable was defined).
For plays/tasks this is also true for ``remote_user``::
For plays/tasks this is also true for ``remote_user``. Assuming the same inventory config, the following play::
- hosts: myhost - hosts: myhost
tasks: tasks:
- command: i'll connect as ramon still - command: i'll connect as ramon still
remote_user: lola remote_user: lola
This is done so host-specific settings can override the general settings. These variables are normally defined per host or group in inventory, will have the value of `remote_user` overwritten by `ansible_ssh_user` in the inventory.
but they behave like other variables. If you want to override the remote user globally (even over inventory) you can use extra vars::
ansible... -e "ansible_user=<user>" This is done so host-specific settings can override the general settings. These variables are normally defined per host or group in inventory,
but they behave like other variables.
If you want to override the remote user globally (even over inventory) you can use extra vars. For instance, if you run::
ansible... -e "ansible_user=maria" -u lola
the `lola` value is still ignored, but `ansible_user=maria` takes precedence over all other places where `ansible_user` (or `ansible_ssh_user`, or `remote_user`) might be set.
You can also override as a normal variable in a play:: You can also override as a normal variable in a play::