special_vars are a flavor of host specific task vars

[sivel]

SUMMARY

special_vars are a flavor of host specific task vars. ci_complete

The issue here is that IncludedVars uses 5 things for uniqueness:

1. Included filename
2. Include args
3. "special" vars (primarily loop related variables)
4. task uuid
5. parent task uuid

There is currently a 1:1 relationship between IncludedFile and special_vars. So if the loop is dependent on a host variable, special_vars will differ per host, creating a 1:1 relationship between IncludedFile and Host. Whereas the expectation is to have a 1:many relationship.

This PR creates a new dataclass specifically for handling this, and removing the vars comparison, but continuing to link it with the host, but without changing the existing variable precedence.

So this change tracks the vars with the host, but doesn't use the vars for comparisons. It then creates copies of the task for the hosts, and merges the vars.

Another solution may be to add a new step in the variable precendence rules for this use, instead of copying the task, and merging the task vars.

Reproducer:

---
- hosts: all
  gather_facts: false
  vars:
    test_variable:
      - "{{ inventory_hostname[-1]|int }}"
  tasks:
    - include_tasks: do_something.yml
      loop: "{{ test_variable }}"

localhost0 ansible_connection=local
localhost1 ansible_connection=local
localhost2 ansible_connection=local
localhost3 ansible_connection=local
localhost4 ansible_connection=local

[all:vars]
ansible_python_interpreter={{ansible_playbook_python}}

ISSUE TYPE

• Bugfix Pull Request

Addditional Context

Outputs:

devel...

TASK [include_tasks] ***********************************************************
included: /Users/sivel/projects/ansibledev/playbooks/36978/do_something.yml for localhost0
included: /Users/sivel/projects/ansibledev/playbooks/36978/do_something.yml for localhost1 => (item=1)
included: /Users/sivel/projects/ansibledev/playbooks/36978/do_something.yml for localhost2 => (item=2)
included: /Users/sivel/projects/ansibledev/playbooks/36978/do_something.yml for localhost3 => (item=3)
included: /Users/sivel/projects/ansibledev/playbooks/36978/do_something.yml for localhost4 => (item=4)

TASK [debug] *******************************************************************
ok: [localhost0] => {
    "msg": "0 something"
}

TASK [debug] *******************************************************************
ok: [localhost1] => {
    "msg": "1 something"
}

TASK [debug] *******************************************************************
ok: [localhost2] => {
    "msg": "2 something"
}

TASK [debug] *******************************************************************
ok: [localhost3] => {
    "msg": "3 something"
}

TASK [debug] *******************************************************************
ok: [localhost4] => {
    "msg": "4 something"
}

This PR...

TASK [include_tasks] ***********************************************************
included: /Users/sivel/projects/ansibledev/playbooks/36978/do_something.yml for localhost0, localhost1, localhost2, localhost3, localhost4 => (item=<various>)

TASK [debug] *******************************************************************
ok: [localhost0] => {
    "msg": "0 something"
}
ok: [localhost1] => {
    "msg": "1 something"
}
ok: [localhost2] => {
    "msg": "2 something"
}
ok: [localhost3] => {
    "msg": "3 something"
}
ok: [localhost4] => {
    "msg": "4 something"
}

[bcoca]

+1 for this approach, I really don't think we should add yet another level of variable precedence ...

[sivel]

I want to call attention to this change. This can be a performance degradation, but without making copies of the block for each host, this approach falls apart. Generally speaking it is not likely to be a source of trouble, but worth reviewing this carefully.

[mkrizek]

In my testing at least the wall clock time dropped with this PR.

We could probably (micro-)optimize the Block.copy() method as well (which I started playing with in #86936).

[mkrizek]

A couple of minor suggestions but 👍🏻 overall.

[mkrizek]

In my testing at least the wall clock time dropped with this PR.

We could probably (micro-)optimize the Block.copy() method as well (which I started playing with in #86936).