Ansible 2.2 inconsistent include_vars behaviour (with/without register)

[berlic]

ISSUE TYPE

• Bug Report

COMPONENT NAME

include_var (may be some other facts-generating modules/plugins)

ANSIBLE VERSION

2.2.1

CONFIGURATION

Default

OS / ENVIRONMENT

N/A

SUMMARY

In the following vars file my_list and my_list2 dict keys gives different results depending on whether we register results or not.

STEPS TO REPRODUCE

Vars file w61_vars.yml:

---
my_dict:
  my_string: "{{ some_string }}"
  my_list: ["{{ some_string }}", "world"]      # list with templated item
  my_list2: "{{ [some_string] + ['world'] }}"  # templated list

Playbook file w61.yml:

---
- hosts: localhost
  gather_facts: no
  vars:
    some_string: hello
  tasks:
    - include_vars:
        file: w61_vars.yml
        name: test_var
      # without register keyword

    - debug: msg="{{ test_var }}"

    - include_vars:
        file: w61_vars.yml
        name: test_var
      register: incl

    - debug: msg="{{ test_var }}"

EXPECTED RESULTS

Debug module should produce equal result in each case.

ACTUAL RESULTS

my_list is templated without register and is not templated with register keyword.

PLAY [localhost] ***************************************************************

TASK [include_vars] ************************************************************
ok: [localhost] => {"ansible_facts": {"test_var": {"my_dict": {"my_list": ["{{ some_string }}", "world"], "my_list2": "{{ [some_string] + ['world'] }}", "my_string": "{{ some_string }}"}}}, "changed": false}

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": {
        "my_dict": {
            "my_list": [
                "hello",
                "world"
            ],
            "my_list2": [
                "hello",
                "world"
            ],
            "my_string": "hello"
        }
    }
}

TASK [include_vars] ************************************************************
ok: [localhost] => {"ansible_facts": {"test_var": {"my_dict": {"my_list": ["{{ some_string }}", "world"], "my_list2": "{{ [some_string] + ['world'] }}", "my_string": "{{ some_string }}"}}}, "changed": false}

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": {
        "my_dict": {
            "my_list": [
                "{{ some_string }}",
                "world"
            ],
            "my_list2": [
                "hello",
                "world"
            ],
            "my_string": "hello"
        }
    }
}

In Ansible 2.2.0 result with register is even weirder:

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": {
        "my_dict": {
            "my_list": [
                "{# some_string #}",
                "world"
            ],
            "my_list2": "{# [some_string] + ['world'] #}",
            "my_string": "{# some_string #}"
        }
    }
}

[ansibot]

cc @bennojoy
click here for bot help

[burns498]

Similar issue for ansible 2.1.1.0. With 2.1 I can't fallback on include_vars "name" option either.

I've been wrestling with this for awhile so I'm glad I found this open issue. Has a fix or workaround been identified?

Thank you.

[RobertKozak]

This is still happening with 2.3. I was fighting this all afternoon until I realized it was a bug.

The name property of include_vars works fine for me with 2.3

[ansibot]

cc @linuxdynasty
click here for bot help

[bennojoy]

This seems to be happening because of
https://github.com/ansible/ansible/blob/devel/lib/ansible/executor/task_executor.py#L541
and https://github.com/ansible/ansible/blob/devel/lib/ansible/executor/task_executor.py#L612

where the variable is marked as 'unsafe' and hence not templated by the Templar:

https://github.com/ansible/ansible/blob/devel/lib/ansible/template/__init__.py#L401

i am not sure what would be the best way to fix this since i am not sure of the security implications so i defer it to the experts :)

[DylanYoung]

This is likely also fixed by this PR, as is 36024 (see above), a related and replicated bug that was closed for some reason :(

If I can get some confirmation that it will be merged, I'm happy to get it up-to-date (again sigh)

Is anyone here willing to write some tests or give me some pointers on what tests are needed for core functionality like this and where they should live?

That's the only piece I'm missing.

[konstantin-schura]

the same for 2.9.6 :(

[DylanYoung]

Over 2 years now that PR has been languishing. It's such a huge improvement to ansible core :(

[DylanYoung]

But I just can't put the time into keeping it constantly up to date with no expressed interest in reviewing or merging it.

Happy to do so if you can get some ansible dev attention :)

[webmozart]

I just stumbled across this issue - still happening with Ansible 2.10.5 :(