Deprecate directive 'remote_user' in favor of 'ansible_user' vars

[dagwieers]

Proposal: directive-cleanup

Author: Dag Wieers <@dagwieers> dag

Date: 2017/12/13

• Status: New
• Proposal type: core design
• Targeted Release: future release
• Associated PR: <link to GH PR in ansible/proposals if PR was submitted>
• Estimated time to implement: uncertain

Motivation

So we have a few directives (remote_user comes to mind) that overrides default configuration settings, e.g. at the task level. However according to variable precedence remote_user does not win over ansible_user defined in your inventory, which is very confusing and is not logical. While in this case defining them as task vars will do the job correctly as well.

So my proposal is to deprecate some of these directives in favor of using ansible_ vars.

Solution proposal

The below may not work if ansible_user was set in the inventory.

  - module:
    remote_user: foo

We could deprecate the above in favor of:

  - module:
    vars:
      ansible_user: foo

Which would always work, despite what was put in the inventory.

Dependencies (optional)

As part of this, we could identify similar directives we could deprecate.

Example support questions

• https://github.com/ansible/ansible/issues/33782
• https://github.com/ansible/ansible/issues/30360
• https://github.com/ansible/ansible/issues/28551
• https://github.com/ansible/ansible/issues/24409
• https://github.com/ansible/ansible/issues/30360

[bushvin]

@dagwieers you read my mind... ;)

[bcoca]

First remote_user is a keyword, applicable to playbook objects, variables like ansible_user/ansible_ssh_user can be declared as overrides for the generic keyword, both have a reason to exist and allow for setting to allow for 'general for task, but allow exceptions for specific hosts/groups' scenario, among others.

There is a complexity and confusion inherit in having many ways of setting an option, but it is currently needed to cover many different real life scenarios. The docs about configuration precedence should be enough to clarify the issue (or should be iterated upon until they are). As such I'm going to close this proposal as 'rejected'.