Fix warning consistency and internal clobbers

[bcoca]

ISSUE TYPE

• Bugfix Pull Request

[bcoca]

nvmd

[mattclay]

@bcoca Can you resolve the CI issues on this PR? I'd like to wait until it's passing before I review it.

[s-hertel]

This change seems like a good improvement, will add warnings for 43 (in my latest count) internal variables. I think we should reduce the erroneous warnings too. Adding/removing warnings doesn't impact playbook behavior, so I think those changes specifically should be backported.

I tested name with various types of params (since you gave it as a reason why we can't just basically delete https://github.com/ansible/ansible/blob/v2.18.5/lib/ansible/vars/reserved.py#L38-L65), back to 2.2 before the original warning was added. I don't see a compelling reason to keep a warning for that.

playbook.yml

# Comment out the rest of the playbook for each test, as warnings are deduplicated. The comments are a summary of that process.
- hosts: localhost
  gather_facts: no
  roles:
    - name: role1  # no warning, of course - params never emit a warning, this has been consistent
      vars:
        role: warning from 2.3 (f4b6b72c5b009d6b9eb947382b38f3e337d264b7) to 2.15 (0b678d5036f64f95d50d73d3d27a523a2b264050), 2.17.8+/2.18.2+ (819e437d967e33f7331cbc28e7d18920f7fa5740 / 3e22739cc8e9542c070e561d5e8457df594c9669).

    - role: role1
      name: no warning
      vars:
        name: warning from 2.3 (f4b6b72c5b009d6b9eb947382b38f3e337d264b7) to 2.15 (0b678d5036f64f95d50d73d3d27a523a2b264050), 2.17.8+/2.18.2+ (819e437d967e33f7331cbc28e7d18920f7fa5740 / 3e22739cc8e9542c070e561d5e8457df594c9669).
  tasks:
    # Tested 2.3 through 2.15 since include does not exist in 2.16.
    - include:
        _raw_params: roles/role1/tasks/main.yml
        name: no warning
        vars:
          name: no warning

    # Tested 2.4 through devel, since it doesn't exist in 2.3.
    - import_role:
        name: role1
      vars:
        name: warning from 2.7 (27b4d7ed31b6688253fc4089b7a6b97f2d548167) to 2.15 (0b678d5036f64f95d50d73d3d27a523a2b264050), 2.17.8+/2.18.2+ (819e437d967e33f7331cbc28e7d18920f7fa5740 / 3e22739cc8e9542c070e561d5e8457df594c9669).

    # Tested 2.3 through devel since include_role does not exist in 2.2.
    - include_role:
        name: role1
      vars:
        name: warning from 2.17.8+/2.18.2+ (819e437d967e33f7331cbc28e7d18920f7fa5740 / 3e22739cc8e9542c070e561d5e8457df594c9669).

roles/role1/meta/main.yml

dependencies:
  - role: role2
    name: no warning
    vars:
       name: warning from 2.3 (f4b6b72c5b009d6b9eb947382b38f3e337d264b7) to 2.15 (0b678d5036f64f95d50d73d3d27a523a2b264050), 2.17.8+/2.18.2+ (819e437d967e33f7331cbc28e7d18920f7fa5740 / 3e22739cc8e9542c070e561d5e8457df594c9669).

name is fully defined by the user, ansible does not create it or utilize it magically anywhere. The warning makes it appear as though there is a problem when it works like normal variable precedence, nothing to warn over.

It's right twice...

environment
vars

and wrong 62 times - all variables ansible warns about, but does not create/utilize.

action
always
any_errors_fatal
args
async
async_val
become
become_exe
become_flags
become_method
become_user
block
changed_when
check_mode
collections
connection
debugger
delay
delegate_facts
delegate_to
diff
fact_path
failed_when
force_handlers
gather_facts
gather_subset
gather_timeout
handlers
hosts
ignore_errors
ignore_unreachable
local_action
loop
loop_control
loop_with
max_fail_percentage
module_defaults
name
no_log
notify
order
poll
port
post_tasks
pre_tasks
register
remote_user
rescue
retries
roles
run_once
serial
strategy
tags
tasks
throttle
timeout
until
vars_files
vars_prompt
when
with_

If we remove that block of code, then we'd just need to add environment and vars to INTERNAL_STATIC_VARS.

[bcoca]

I'll setup an example, the name you are using above is something we fixed long ago, it was just the thing that alerted us to the issue. Passing vars inline is not an issue, passing a variable inline that collides with role defs was. Though I suspect you are correct about it being needed anymore, we've restructured how all this worked and never had tests to check if the conflict was still there or resolved.

[mattclay]

@bcoca Can you resolve the CI issues on this PR? I'd like to wait until it's passing before I review it.

[bcoca]

@mattclay i still have unanswered questions, specially when it comes to ansible_local and it's
'overwrittablity'