This is indeed expected and is documented at https://docs.ansible.com/ansible/latest/porting_guides/porting_guide_2.7.html#include-role-and-import-role-variable-exposure

If you have further questions please stop by IRC or the mailing list:

• IRC: #ansible on irc.freenode.net
• mailing list: https://groups.google.com/forum/#!forum/ansible-project

Perhaps you have not read my issue correctly. If the behaviour is intended by this statement:

"import_role does not support the public argument, and will unconditionally expose the role’s defaults and vars to the rest of the playbook. This functionality brings import_role into closer alignment with roles listed within the roles header in a play."

then:-

1. the statement is wrongly worded as import_role now behave VERY differently to 'roles listed within the roles header in a play', and
2. the change is badly implemented as it does not behave that way if the roles: keyword exists (even with empty list of roles), so the result is really very unexpected behaviour.
3. the docs page on variable precedence is now getting woefully out of whack with the implementation behaviour.

I will admit that I read your issue multiple times. However I struggled to see a problem outside of the documentation and implementation.

However, it seems I was wrong.

I've updated the title to better reflect your problem, in that vars from import_role seem to be persisting across plays, and more specifically, only when no roles are listed under the roles header within a play.

An example that misbehaves:

- hosts: localhost
  gather_facts: false
  tasks:
    - import_role:
        name: foo

    - debug:
        var: thing

- hosts: localhost
  gather_facts: false
  tasks:
    - debug:
        var: thing

This should produce the following in the 2nd play, but it does not.

ok: [localhost] => {
    "thing": "VARIABLE IS NOT DEFINED!: 'thing' is undefined"
}

When any other role is listed under roles:, then it behaves correctly.

Yes. I have no idea what is expected/correct though, only what it did before. The porting guide clearly says expose to the rest of playbook (not rest of play) - which is very new behaviour.

Just as an update here, the problem is that roles is defined in Play with a mutable default value.

As such, if roles is not listed in the play, then Play.roles isn't overridden per play, and instead the value is mutated across all plays.

This is a potentially big problem for the future, so I'm going to look into a solution to address that root cause, instead of a one off for just roles.

I was thinking this scoping issue in general was likely to hit big problems if not well defined. I only came across this particular issue while trying to improve my own docs.

What would be most useful is to know what the ansible team want the scoping to work in the long term.

For your reference I am pasting the current incarnation of my attempt to document it - if only for you to see that it is seems more complex than the docs suggest, at least to me.

AnsibleVarsPrecedence.pdf

Sorry, hit the wrong button :-)

Hi @torched99, thank you for submitting this issue!

click here for bot help