From 7988266bb7d887165b0e84794b8a8469d3a537b1 Mon Sep 17 00:00:00 2001 From: James Polley Date: Fri, 31 Aug 2018 23:56:58 +1000 Subject: [PATCH] Improve clarity of precedence when command-line parameters are used. (#39059) * 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. --- .../rst/user_guide/playbooks_variables.rst | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/docs/docsite/rst/user_guide/playbooks_variables.rst b/docs/docsite/rst/user_guide/playbooks_variables.rst index aaf289dd93a..9db4432de0a 100644 --- a/docs/docsite/rst/user_guide/playbooks_variables.rst +++ b/docs/docsite/rst/user_guide/playbooks_variables.rst @@ -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): + * command line values (eg "-u user") * role defaults [1]_ * inventory file or script group vars [2]_ * 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/. -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 -This will still connect as ``ramon`` because ``ansible_ssh_user`` is set to ``ramon`` in inventory for myhost. -For plays/tasks this is also true for ``remote_user``:: +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``. Assuming the same inventory config, the following play:: - hosts: myhost tasks: - command: i'll connect as ramon still remote_user: lola +will have the value of `remote_user` overwritten by `ansible_ssh_user` in the inventory. + 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:: +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 - ansible... -e "ansible_user=" +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::