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

Redefining variables from 'meta' (different behavior in 1.9, 2.0-rc and 2.0.0.2) #14411

Closed
serge-name opened this issue Feb 10, 2016 · 1 comment
Labels
bug This issue/PR relates to a bug.

Comments

@serge-name
Copy link

Hello,

I've got a bunch of playbooks written initially for ansible 1.9 by my precedessor. Recently I tried to adapt it to ansible 2.0 and discovered the difference in variable hadling when you override defaults in 'meta/main.yml'. I'd like know whether it's a bug or feature :)

I've tried 3 versions of Ansible:

ansible 1.9.4

ansible 2.0.0 (detached HEAD cc98528) last updated 2015/12/19 18:44:56 (GMT +300)
lib/ansible/modules/core: (detached HEAD fcb3397) last updated 2015/12/19 18:44:51 (GMT +300)
lib/ansible/modules/extras: (detached HEAD c682975) last updated 2015/12/19 18:44:56 (GMT +300)

ansible 2.0.0.2 (detached HEAD 7de237c) last updated 2016/01/21 23:40:54 (GMT +300)
lib/ansible/modules/core: (detached HEAD 09e2457) last updated 2016/01/21 23:40:48 (GMT +300)
lib/ansible/modules/extras: (detached HEAD e8427cb) last updated 2016/01/21 23:40:54 (GMT +300)

First, I going to show a test code (also here: https://github.com/serge-name/test-override-var):

playbook.yml:

- name: test
  hosts: localhost
  gather_facts: False

  roles:
    - test-override-var1

test-override-var1/meta/main.yml:

dependencies:
  - test-override-var3
  - test-override-var2

test-override-var1/tasks/main.yml:

- debug: msg=">>{{ the_var }}<<"

test-override-var1/meta/main.yml:

dependencies:
  - role: test-override-var3
    the_var: '2'

test-override-var3/defaults/main.yml:

the_var: '3'

test-override-var3/tasks/main.yml:

- debug: msg=">>{{ the_var }}<<"

On ansible-1.9 I get the following sequence (the desired behavior):

TASK: [test-override-var3 | debug msg=">>{{ the_var }}<<"] ******************** 
ok: [localhost] => {
    "msg": ">>3<<"
}

TASK: [test-override-var3 | debug msg=">>2<<"] ******************************** 
ok: [localhost] => {
    "msg": ">>2<<"
}

TASK: [test-override-var1 | debug msg=">>{{ the_var }}<<"] ******************** 
ok: [localhost] => {
    "msg": ">>3<<"
}

On ansible-2.0-rc I get the following (and it gives me problems):

TASK [test-override-var3 : debug msg=>>{{ the_var }}<<] ************************
ok: [localhost] => {
    "changed": false, 
    "msg": ">>3<<"
}

TASK [test-override-var3 : debug msg=>>{{ the_var }}<<] ************************
ok: [localhost] => {
    "changed": false, 
    "msg": ">>2<<"
}

TASK [test-override-var1 : debug msg=>>{{ the_var }}<<] ************************
ok: [localhost] => {
    "changed": false, 
    "msg": ">>2<<"
}

On ansible-2.0.0.2 I get the following (problems again):

TASK [test-override-var3 : debug] **********************************************
ok: [localhost] => {
    "msg": ">>2<<"
}

TASK [test-override-var3 : debug] **********************************************
ok: [localhost] => {
    "msg": ">>2<<"
}

TASK [test-override-var1 : debug] **********************************************
ok: [localhost] => {
    "msg": ">>2<<"
}
@jimi-c
Copy link
Member

jimi-c commented May 11, 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 May 12, 2016
In VariableManager, we fetch the params specifically in the next step,
so including them in the prior step is unnecessary and could lead to things
being overridden in an improper order.

In Block, we should not be getting the params for the role as they are
included earlier via the VariableManager.

Fixes #14411
gescheit pushed a commit to gescheit/ansible that referenced this issue Jun 3, 2016
In VariableManager, we fetch the params specifically in the next step,
so including them in the prior step is unnecessary and could lead to things
being overridden in an improper order.

In Block, we should not be getting the params for the role as they are
included earlier via the VariableManager.

Fixes ansible#14411
@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.
Projects
None yet
Development

No branches or pull requests

4 participants