Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Variables in role dependencies not correctly scoped so defaults are overriden by different role invocations in Ansible 2.0.0.2 #14472

Closed
dwcramer opened this issue Feb 14, 2016 · 3 comments
Labels
bug This issue/PR relates to a bug. P2 Priority 2 - Issue Blocks Release
Milestone

Comments

@dwcramer
Copy link

If I have a role that I use multiple times in the same playbook with different variables each time, a variable declared in one invocation of the role will override defaults in other invocations of the same role.

I've committed a playbook with roles that illustrates the problem: https://github.com/dwcramer/ansible-bug

Notice that the role example2 depends on the role example more than one time but passes different variables each time. The effect would also exist if I have several different roles depending on the same role with different variables passed in. For example, say I'm using a role that sets up upstart jobs for different services I lay down.

Notice that in Ansible 2.x, a value assigned to a variable in one invocation of the role (some_variable: [1,2] overrides the default in all invocations of the role, not just the one to which it applies.

A workaround is to explicitly assign a value to the role each time you invoke it, but that's not how it should work.

The actual output of this playbook is:

davcrame@DAVCRAME-M-G095 ~/dsx/ansible-bug
$ ansible-playbook -i inventory playbook.yml

PLAY ***************************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [example : Print example variable] ****************************************
ok: [localhost] => {
    "some_variable": [
        1,
        2
    ]
}

TASK [example : Print example variable] ****************************************
ok: [localhost] => {
    "some_variable": [
        1,
        2
    ]
}

TASK [example : Print example variable] ****************************************
ok: [localhost] => {
    "some_variable": [
        1,
        2
    ]
}

PLAY RECAP *********************************************************************
localhost                  : ok=4    changed=0    unreachable=0    failed=0

The expected output and the output from Ansible 1.9.x is:

davcrame@DAVCRAME-M-G095 ~/dsx/ansible-bug (master)
$ ansible-playbook -i inventory playbook.yml

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

GATHERING FACTS ***************************************************************
ok: [localhost]

TASK: [example | Print example variable] **************************************
ok: [localhost] => {
    "var": {
        "some_variable": "False"
    }
}

TASK: [example | Print example variable] **************************************
ok: [localhost] => {
    "var": {
        "some_variable": [
            1,
            2
        ]
    }
}

TASK: [example | Print example variable] **************************************
ok: [localhost] => {
    "var": {
        "some_variable": "False"
    }
}

PLAY RECAP ********************************************************************
localhost                  : ok=4    changed=0    unreachable=0    failed=0
@jimi-c jimi-c added this to the stable-2.0 milestone Feb 24, 2016
@jimi-c jimi-c added the P2 Priority 2 - Issue Blocks Release label Feb 24, 2016
mscherer added a commit to OSAS/ansible-role-httpd that referenced this issue Feb 29, 2016
Trying to fix earlier issue resulted into me bumping in another bug:
ansible/ansible#14472

So this is a workaround to not touch to variable until the scoping is
right.
@krtek4
Copy link

krtek4 commented Mar 1, 2016

I am encountering a variation of this issue, when I have a role with a dependency, say something along the lines of :

- { role: supervisor, service_name: "solr", user: "solr", command: "{{ solr_command }}", root_directory: "{{ solr_install_dir }}" }

All subsequent reference to root_directory in the following roles will now have the value of solr_install_dir instead of the "original" value.

This happened to work as I expect in latest Ansible versions.

@faern
Copy link

faern commented Mar 14, 2016

I'm having the same problem in 2.0.1.0.

jimi-c added a commit that referenced this issue Mar 20, 2016
* Make role param resolution follow the role dependency chain, rather
  than using all roles within the play
* Also move params to be merged in after role vars in general, to match
  our variable precedence rules
* Changes to the way var lookup is done in role helper methods for
  get_vars(), get_inherited_vars(), and get_role_params() to make the
  above possible without trampling on previously merged vars

Fixes #14472
Fixes #14475
@jimi-c jimi-c closed this as completed in 9d2fe2f Mar 20, 2016
@jimi-c
Copy link
Member

jimi-c commented Mar 20, 2016

Closing This Ticket

Hi!

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

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:

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 added a commit that referenced this issue Mar 21, 2016
* Make role param resolution follow the role dependency chain, rather
  than using all roles within the play
* Also move params to be merged in after role vars in general, to match
  our variable precedence rules
* Changes to the way var lookup is done in role helper methods for
  get_vars(), get_inherited_vars(), and get_role_params() to make the
  above possible without trampling on previously merged vars

Fixes #14472
Fixes #14475
@ansibot ansibot added bug This issue/PR relates to a bug. and removed bug_report labels Mar 7, 2018
@ansible ansible locked and limited conversation to collaborators Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug This issue/PR relates to a bug. P2 Priority 2 - Issue Blocks Release
Projects
None yet
Development

No branches or pull requests

5 participants