Assuming I read the playbooks right, I think the problem, at least for 2.0.1.0, seems to be that variables from previous runs of the role are allowed to bleed into later runs. I have some playbooks that have only be run using 1.9.x that do multiple includes of the same role, and conditionals within the roles are being executed with previous values of the variables used in the condition. I can't speak to what's going on in 2.1; @pcastellazzi was rather vague as to what the actual correct behavior was, only that it's inconsistent between versions.

I would expect that the correct behavior is that any role variables are reset to defaults when the role is executed again, and any variable set for previous role execution that do not have defaults should be deleted. In other words, subsequent runs of a role should occur in a clean, isolated environment without pollution from previous runs. I should be able to reason about how a role will run based solely on the input variables, without any knowledge of the environment that exists around the role.

Sorry i was not clear enough. Variable bleeding is an issue, yes, but that's not what i meant with inconsistent. i.e.: With ansible 1.9.6 test1.yml run role1 4 times, the same as test3.yml, but test2.yml run it 3 times, even with allow_duplicates: yes.

It's my understanding that each unique role should be executed once, and a unique role include its parameters. A call to {role: rol1, a: 1} it is different from {role: rol1, a: 2}. If that's the case test2.yml is given the correct output, but it should not do it because allow_duplicates: yes was used. An output similar to test1.yml and test3.yml is expected.

When you run this with ansible 2.x role1 is run 3 times on every case, which is again wrong because, for test2.yml it should run 4 times due to allow_duplicates: yes.

# test1.yml
TASK: [role1 | debug msg="[1, 3, 5]"] *****************************************
TASK: [role1 | debug msg="[Undefined, Undefined, Undefined]"] *****************
TASK: [role1 | debug msg="[2, 4, 6]"] *****************************************
TASK: [role1 | debug msg="[Undefined, Undefined, Undefined]"] *****************

# test2.yml
TASK: [role1 | debug msg="[1, 3, 5]"] *****************************************
TASK: [role1 | debug msg="[Undefined, Undefined, Undefined]"] *****************
TASK: [role1 | debug msg="[2, 4, 6]"] *****************************************

# test3.yml
TASK: [role1 | debug msg="[1, 3, 5]"] *****************************************
TASK: [role1 | debug msg="[Undefined, Undefined, Undefined]"] *****************
TASK: [role1 | debug msg="[2, 4, 6]"] *****************************************
TASK: [role1 | debug msg="[Undefined, Undefined, Undefined]"] *****************

There is one more inconsistency noticed

Following scenario

roles:

• role1
• role1

With this role 1 gets executed twice, without setting allow_duplicates:yes

But for the following scenario

roles:

• role1
• role2
• role1

Second instance to role1 only gets executed if allow_duplicates: yes is set. I have tried this on ansible 2.1, 2.2 and devel 2.3 they all have same behaviour.

Closing This Ticket

Hi!

We believe the above commit should resolve this problem for you. This will also be included in the next release.

Do note however, that roles instantiated with different parameters are not considered duplicates, so for most of the examples in the original run you will see multiple invocations of the role.

If you continue seeing any problems related to this issue, or 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!