carlos.e
(Carlos)
August 5, 2025, 3:52am
1
I was trying to use different entry points for a role depending on ansible_facts['system']
var.
The following example role has only 2 task files:
Linux.yml
:
---
- name: Assert
ansible.builtin.assert:
that:
- ansible_facts['system'] == 'Linux'
...
Win32NT.yml
:
---
- name: Assert
ansible.builtin.assert:
that:
- ansible_facts['system'] == 'Win32NT'
...
Playbook test1.yml
:
---
- name: Play
hosts: all
tasks:
- name: Include role
ansible.builtin.include_role:
name: test
tasks_from: "{{ ansible_facts['system'] }}"
...
Lets say we have a Windows host named win1
, and a Linux host named lin1
The problem only occurs when you mix Windows and Linux hosts in the same run:
ansible-playbook test1.yml -l 'win1,lin1'
PLAY [Play] *********************************************************************************************************************************
TASK [Include role] *************************************************************************************************************************
included: test for lin1, win1
TASK [test : Assert] ************************************************************************************************************************
ok: [lin1] =>
changed: false
msg: All assertions passed
[ERROR]: Task failed: Action failed: Assertion failed
Origin: /home/carlos/repos/vfmsa_roles/roles/test/tasks/Linux.yml:2:3
1 ---
2 - name: Assert
^ column 3
fatal: [win1]: FAILED! =>
assertion: ansible_facts['system'] == 'Linux'
changed: false
evaluated_to: false
msg: Assertion failed
PLAY RECAP **********************************************************************************************************************************
lin1 : ok=2 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
win1 : ok=1 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0
Ansible is using Linux.yml
for all hosts.
There are no issues when running the playbook with each host independently.
Is what I’m trying to do legal ? If not: why?
Ansible version: 2.19.0
The same problem occurs with 2.18
sivel
(sivel)
August 5, 2025, 2:02pm
2
I believe we have a bug report detailing this already:
opened 02:19PM - 15 Jan 20 UTC
easyfix
module
support:core
bug
has_pr
affects_2.8
P3
verified
affects_2.9
##### SUMMARY
We're trying to implement roles, which can be individualized by… supplying host related vars files. This doesn't seem to work under certain circumstances. Up to now we're not yet sure, whether this is a bug or works as designed.
##### ISSUE TYPE
- Bug Report
##### COMPONENT NAME
include_role
##### ANSIBLE VERSION
```paste below
ansible 2.9.9
config file = /adm/afroebel/ansible/unix/ansible.cfg
configured module search path = [u'/adm/afroebel/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python2.7/dist-packages/ansible
executable location = /usr/bin/ansible
python version = 2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0]
```
##### CONFIGURATION
```paste below
DEFAULT_GATHERING(/adm/afroebel/ansible/unix/ansible.cfg) = explicit
DEFAULT_MANAGED_STR(/adm/afroebel/ansible/unix/ansible.cfg) = {file}
DEFAULT_PRIVATE_ROLE_VARS(/adm/afroebel/ansible/unix/ansible.cfg) = True
PERSISTENT_CONNECT_TIMEOUT(/adm/afroebel/ansible/unix/ansible.cfg) = 30
```
##### OS / ENVIRONMENT
Ansible controller: Debian GNU/Linux 10
managed devices: Oracle Solaris 11.3/11.4
##### STEPS TO REPRODUCE
We've got 3 simple roles with exactly the same content, one task file and two vars files named like ansible hosts:
```yaml
# cksum test/roles/test_role/*/*/*
201185725 22 test/roles/test_role/solaris/tasks/main.yml
1196793317 19 test/roles/test_role/solaris/vars/test07
2721971076 19 test/roles/test_role/solaris/vars/test08
201185725 22 test/roles/test_role/test07/tasks/main.yml
1196793317 19 test/roles/test_role/test07/vars/test07
2721971076 19 test/roles/test_role/test07/vars/test08
201185725 22 test/roles/test_role/test08/tasks/main.yml
1196793317 19 test/roles/test_role/test08/vars/test07
2721971076 19 test/roles/test_role/test08/vars/test08
# cat test/roles/test_role/solaris/tasks/main.yml
---
- debug: var=var1
# cat test/roles/test_role/solaris/vars/test07
---
var1: "test07"
# cat test/roles/test_role/solaris/vars/test08
---
var1: "test08"
```
We now executed the playbook test/include_role.yml:
```yaml
---
- name: "Test Playbook"
hosts: "test07:test08"
tasks:
- include_role:
name: "test_role/{{ inventory_hostname_short}}"
vars_from: "{{ inventory_hostname_short }}"
```
It worked well and produced the following output:
```yaml
# ansible-playbook -i inventory test/include_role.yml
PLAY [Test Playbook] *******************************************************************
TASK [include_role : test_role/{{ inventory_hostname_short}}] **************************
TASK [test_role/test07 : debug] ********************************************************
ok: [test07] => {
"var1": "test07"
}
TASK [test_role/test08 : debug] ********************************************************
ok: [test08] => {
"var1": "test08"
}
PLAY RECAP *****************************************************************************
test07: ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
test08: ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
```
Tracing the ansible-playbook command using strace revealed, that tasks and vars files of either role were actually opened and read from.
The playbook test/include_role.yml was slightly changed in order to include a generic role test_role/solaris instead of the host related roles.
```yaml
---
- name: "Test Playbook"
hosts: "test07:test08"
tasks:
- include_role:
name: "test_role/solaris"
vars_from: "{{ inventory_hostname_short }}"
```
##### EXPECTED RESULTS
As the content of the generic role was exactly the same as the content of the host related roles, we would expect the playbook to produce the same output.
##### ACTUAL RESULTS
Even though the host related vars files contained different values for variable var1, ansible only used one of them during execution.
```yaml
# ansible-playbook -i inventory test/include_role.yml
PLAY [Test Playbook] *******************************************************************
TASK [include_role : test_role/solaris] ************************************************
TASK [test_role/solaris : debug] *******************************************************
ok: [test07] => {
"var1": "test07"
}
ok: [test08] => {
"var1": "test07"
}
PLAY RECAP *****************************************************************************
test07: ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
test08: ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
```
Tracing the ansible-playbook command using strace revealed, that this time only vars file test07 was opened and read from.
carlos.e
(Carlos)
August 5, 2025, 9:25pm
3
I’m not completely sure is the same problem. But anyway, that was supposed to be fixed 3 years ago.
What I want to know first is how to approach this. Is this a known bug? Am I doing something out of best practices? Is it just me? Can someone reproduce it? Should I open a bug report?
mkrizek
(Martin Krizek)
August 6, 2025, 12:17pm
4
As it was already mentioned, yes, it is a known bug reported in a still open issue: include_role sometimes ignores dynamic vars_from parameter · Issue #66497 · ansible/ansible · GitHub
The bug manifests itself on all *_from
options. The bug above specifically mentions vars_from
in its title but it applies to tasks_from
too as you are seeing in your playbook.
bcoca
(Brian Coca)
August 7, 2025, 2:43pm
5
carlos.e
(Carlos)
August 7, 2025, 3:22pm
6
Awsome!
That did the trick. thank you.