Nested task includes when passed a list to iterate over, receive the list passed to the outermost parent.

[stewartm]

Issue Type:

Bug Report

Ansible Version:

[ansible@testhost1 ~]$ ansible --version
ansible 2.0.1.0 (stable-2.0 8ca8459af5) last updated 2016/02/05 09:14:13 (GMT +100)

Also replicated with:

[ansible@testhost1 ~]$ ansible --version
ansible 2.1.0 (devel 699a854bf3) last updated 2016/02/04 15:32:56 (GMT +100)

Ansible Configuration:

[defaults]

remote_user = ansible
no_target_syslog = True
nocows = 0

[privilege_escalation]
become = yes
become_user = root

(Fact caching had been enabled but I have disabled to troublshoot this issue. Stored cache file has been deleted)

Environment:

Ansible Host = RHEL 6.4
Managed Host = RHEL 6.6

Summary:

Nested task includes when passed a list to iterate over, receive the list passed to the outermost parent.

Steps To Reproduce:

Demonstrated in the following role:

tasks/main.yml
---

- name: Include parent sub tasks
  include: parent_tasks.yml
  with_items: "{{ parent_values }}"

tasks/parent_tasks.yml
---

- name: Include child sub tasks which should iterate over 'child_values', not 'parent_values'
  include: child_tasks.yml
  with_items: "{{ child_values }}"

- name: Demonstrate that normally 'item' is overwritten
  debug: msg="{{ item}}"
  with_items: "{{ child_values }}"

tasks/child_tasks.yml
---

- name: Should be 'child_value' not 'parent_value'?
  debug: msg={{ item }}

defaults/main.yml
---

parent_values:
  - parent_value
child_values:
  - child_value

Expected Results:

I would expect child_tasks.yml to iterate over 'child_values' and therefore the debug task should output 'child_value'

Actual Results:

TASK [include_bug : Should be 'child_value' not 'parent_value'?] ***************
ok: [vpn.clockworknet.com] => {
    "msg": "**parent_value**"
}

TASK [include_bug : Demonstrate that normally 'item' is overwritten] ***********
ok: [vpn.clockworknet.com] => (item=child_value) => {
    "item": "child_value", 
    "msg": "**child_value**"
}

I have also tested additional levels of nesting, but each level always has been passed 'parent_values' as the list to iterate ove

[jimi-c]

Hi @stewartm, this is currently a limitation of using loops with includes, and is documented here: http://docs.ansible.com/ansible/playbooks_loops.html#loops-and-includes

If you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:

• https://groups.google.com/forum/#!forum/ansible-project - for user questions, tips, and tricks
• https://groups.google.com/forum/#!forum/ansible-devel - for strategy, future planning, and questions about writing code

Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved.

Thank you!

[jimi-c]

Hi @stewartm, this is currently a limitation of using loops with includes, and is documented here: http://docs.ansible.com/ansible/playbooks_loops.html#loops-and-includes

If you have any further questions, please let us know by stopping by one of the two mailing lists, as appropriate:

• https://groups.google.com/forum/#!forum/ansible-project - for user questions, tips, and tricks
• https://groups.google.com/forum/#!forum/ansible-devel - for strategy, future planning, and questions about writing code

Because this project is very active, we're unlikely to see comments made on closed tickets, but the mailing list is a great way to ask questions, or post if you don't think this particular issue is resolved.

Thank you!

[stewartm]

Hi @jimi-c. Thanks for getting back to me, however I think the issue has been misinterpreted. I have read the referenced docs and they appear to support my expectation, and contradict the actual result. The docs say:

In 2.0 you are able to use with_ loops and task includes (but not playbook includes), this adds the ability to loop over the set of tasks in one shot. There are a couple of things that you need to keep in mind, a included task that has it’s own with_ loop will overwrite the value of the special item variable. So if you want access to both the include’s item and the current task’s item you should use set_fact to create a alias to the outer one.

This (to me) implies that each included task file when passed a list to iterate over, will reset the 'item' variable in the context of the tasks it contains. As can be seen from my example code, this is not happening. Instead, the 'item' variable is set once on the outer parent, and then is not overwritten within the nested includes. This is contrary to how 'with_items' behaves for tasks other than 'include'. I have updated the parent_tasks.yml example to try and make this clearer.

[stewartm]

Hi @jimi-c. Thanks for getting back to me, however I think the issue has been misinterpreted. I have read the referenced docs and they appear to support my expectation, and contradict the actual result. The docs say:

In 2.0 you are able to use with_ loops and task includes (but not playbook includes), this adds the ability to loop over the set of tasks in one shot. There are a couple of things that you need to keep in mind, a included task that has it’s own with_ loop will overwrite the value of the special item variable. So if you want access to both the include’s item and the current task’s item you should use set_fact to create a alias to the outer one.

This (to me) implies that each included task file when passed a list to iterate over, will reset the 'item' variable in the context of the tasks it contains. As can be seen from my example code, this is not happening. Instead, the 'item' variable is set once on the outer parent, and then is not overwritten within the nested includes. This is contrary to how 'with_items' behaves for tasks other than 'include'. I have updated the parent_tasks.yml example to try and make this clearer.

[moorglade]

FYI, I believe this is the same issue which I reported here: #14146

It seems a number of people have encountered this issue, so it either is a bug, or the documentation is unclear on this specific case.

[moorglade]

FYI, I believe this is the same issue which I reported here: #14146

It seems a number of people have encountered this issue, so it either is a bug, or the documentation is unclear on this specific case.