Variable scope issue: value from a different role being used

Hi all

I’m running from HEAD (recently ran ‘git pull --rebase && git submodule update --init --recursive’ following recent restructuring).

Unfortunately I can’t tell which commit I was previously running from, but I currently have an issue with the value of a variable being used from a different role.

I have the following structure. Real repository details are substituted for privacy but I have been careful to preserve the alphanumerical order of the project names.

deploy.yml

  • name: Configure instance(s) and deploy application
    hosts: launch
    user: root
    gather_facts: true

roles:

  • role: deploy-projectB

tags: deploy
when: project == ‘projectB’ or project == ‘subprojectB’

  • role: deploy-projectA
    tags: deploy
    when: project == ‘projectA’

roles/projectB/tasks/main.yml

  • name: what repo url and dir are we cloning?
    debug: msg=“repo_url={{ repo_url }} repo_dir={{ repo_dir }}”

  • name: Git clone
    git: repo={{ repo_url }}
    dest={{ repo_dir }}
    version={{ repo_branch }}
    accept_hostkey=yes

roles/projectB/vars/main.yml

repo_url: ssh://git@github.com/myorg/projectB.git
repo_dir: /usr/local/projectB/

roles/projectA/vars.yml

repo_url: ssh://git@github.com/myorg/projectA.git
repo_dir: /usr/local/projectA/

Now, when running the following: ansible-playbook -vvvv deploy.yml -e ‘project=projectB repo_branch=feature/blah’

I get the following output and error when the projectB role is being applied (the error is because the origin/feature/blah branch doesn’t exist on the projectA repo)

TASK: [deploy-system | what is going on?] *************************************
<ec2-54-183-209-28.us-west-1.compute.amazonaws.com> ESTABLISH CONNECTION FOR USER: root
ok: [ec2-54-183-209-28.us-west-1.compute.amazonaws.com] => {
“msg”: “repo_branch=feature/blah repo_url=ssh://git@github.com/myorg/projectA.git repo_dir=/usr/local/projectA/”
}

TASK: [deploy-system | Git clone] *********************************************
<ec2-54-183-209-28.us-west-1.compute.amazonaws.com> ESTABLISH CONNECTION FOR USER: root
<ec2-54-183-209-28.us-west-1.compute.amazonaws.com> REMOTE_MODULE git repo=ssh:********@github.com/myorg/projectA.git dest=/usr/local/projectA/ version=feature/blah accept_hostkey=yes
<ec2-54-183-209-28.us-west-1.compute.amazonaws.com> EXEC ssh -C -tt -vvv -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/root/.ansible/cp/ansible-ssh-%h-%p-%r -o StrictHostKeyChecking=no -o Port=22 -o IdentityFile=“/root/.ssh/id_rsa” -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 ec2-54-183-209-28.us-west-1.compute.amazonaws.com /bin/sh -c ‘mkdir -p $HOME/.ansible/tmp/ansible-tmp-1412002786.78-203481241742422 && echo $HOME/.ansible/tmp/ansible-tmp-1412002786.78-203481241742422’
<ec2-54-183-209-28.us-west-1.compute.amazonaws.com> PUT /tmp/tmpAAFWjp TO /root/.ansible/tmp/ansible-tmp-1412002786.78-203481241742422/git
<ec2-54-183-209-28.us-west-1.compute.amazonaws.com> EXEC ssh -C -tt -vvv -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/root/.ansible/cp/ansible-ssh-%h-%p-%r -o StrictHostKeyChecking=no -o Port=22 -o IdentityFile=“/root/.ssh/id_rsa” -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o ConnectTimeout=10 ec2-54-183-209-28.us-west-1.compute.amazonaws.com /bin/sh -c ‘LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 /usr/bin/python2 /root/.ansible/tmp/ansible-tmp-1412002786.78-203481241742422/git; rm -rf /root/.ansible/tmp/ansible-tmp-1412002786.78-203481241742422/ >/dev/null 2>&1’
failed: [ec2-54-183-209-28.us-west-1.compute.amazonaws.com] => {“failed”: true}
msg: Failed to checkout feature/blah

FATAL: all hosts have already failed – aborting

As you can see, the {{ repo_url }} and {{ repo_dir }} variables from projectA are being incorrectly used when applying the projectB role. This was behaving as expected* when running from an [unknown] earlier commit of ansible so I think it was introduced recently.

  • Expected behaviour would be to use the variables from projectB/vars/main.yml

I have ensured that manually performing a git clone and git checkout does really work with the correct details.

Thanks in advance for any input or clarification on what I may have missed, or if it is indeed a bug.

Oh, the role name mismatch between what is in deploy.yml and the following filenames (deploy-projectA vs projectA) really is just a typo (doh).

Tom

Sorry, also the output of ansible --version:

ansible 1.8 (devel 459722899d) last updated 2014/09/29 14:22:39 (GMT +000)
lib/ansible/modules/core: (detached HEAD db5668b84c) last updated 2014/09/29 14:22:47 (GMT +000)
lib/ansible/modules/extras: (detached HEAD 110250d344) last updated 2014/09/29 14:22:52 (GMT +000)
configured module search path = /usr/share/ansible

I have seen this too. I haven’t had time to investigate it yet (I just reverted back to 1.7 in the meantime). Happy to provide more details of my config (although it is similar - two roles with vars, role A picking up vars from role B). I just wanted to reply to the list confirming it’s not just Tom who’s seeing it!

I suppose it might be worth opening a Github issue for it. It does sound like a recently-introduced bug.

Hi, I believe this issue is the same one as discussed above:

https://github.com/ansible/ansible/issues/9219

Please see my comment at the bottom regarding a new feature branch I’ve been working on, which resolves the example playbook in that issue. Additional testing on that new branch would be very welcome!

Thanks!

Role protections, such that variables defined in a role are assuredly used in that role, are a major part of the “great role standdown of 2013”.

We need to fix this ahead of the feature branch, as (A) that feature branch might not hit 1.8, and (B) we need to preserve that role compatibility now.

Hi Tom/Ben, we went ahead and resolved this issue by back-porting some of the code from that feature branch into devel for the time-being, as we’re not ready to merge that feature branch in. If you refresh your development branches, you should get the new code.

Please let us know if you continue seeing any issues related to this.

Thanks!