Weird: Passing variables to roles

Archives Ansible Project
1

Hi,
I have this weird situation where a role doesn’t pick up configured variables, hopefully someone can help me out.
This is parts of my playbook:

  • name: Deploy Elasticsearch VMs
    hosts: localhost
    tags:
  • deploy
    vars:
    os_type: Windows
    public_ip: yes
    use_max_datadisks: True
    create_network_security_group: nsg_eslogging
    create_availability_set: yes
    add_to_adhoc_group: elasticsearch

roles:

  • { role: customer_deploy_azurevm, vm_name: customer-prod-es1}

  • { role: customer_deploy_azurevm, vm_name: customer-prod-es2}

  • name: Deploy logstash VMs
    hosts: localhost
    tags:

  • deploy
    vars:
    os_type: Windows
    public_ip: yes
    max_data_disk_count: 2
    create_network_security_group: nsg_logstash
    create_availability_set: yes
    availability_set_name: as-customer-prod-logstash
    add_to_adhoc_group: logstash
    roles:

  • { role: customer_deploy_azurevm, vm_name: customer-prod-ls1}

  • { role: customer_deploy_azurevm, vm_name: customer-prod-ls2}

The weird thing that happens is that the second play’s vms don’t get the correct availability set (availability_set_name), but they DO get the correct nsg (create_network_security_group). The customer_deploy_azurevm roles works so that if “create_availability_set” is true and “availability_set_name” is not set, then an autogenerated availability set name will be used. This variable seems to “linger” so that the following to vms get the previous auto-generated availability set name (I can see this if I dump all vars before I do anything else in the role)

This seems completely weird to me. Am I doing something wrong, or is this a bug?

2

From what I can see, once a previously undefined variable has been set by a role, the calling playbook is unable to override it on subsequent calls.

3

That is very unexpected.

I pass vars to the same role a lot, although in my case I am usually doing it within the same play (as opposed to within a different play inside the same playbook), and I almost always pass the vars in as -e (extra vars), which from memory have highest precedence.

Looking at your playbook I just wonder if there’s something odd going on to do with the type of the vars. From memory yaml treats unquoted yes and no as boolean true/false values, so it could be that the booleans aren’t getting passed as you’d expect but the strings are.

Maybe it would be worth just experimenting and changing your role so it expects a string for create_availability_set, quoting your “yes” and seeing if that makes a difference.

Feels like a bug to me though if that is the case.

Jon

4

Thanks Jon, I’ll distill it a bit and see what I come up with.

5

Jon (et al), I’ve created this playbook to distill my problem, available here:

https://drive.google.com/file/d/0B81YECbGAyfWaW5rbVRQNlpQT2c/view?usp=sharing

Same thing happens: Then the (previously undefined) variable “variable3” gets set using set_fact within a role, subsequent calls to that role is unable to pass another value for that var. Hopefully I’m doing something wrong, I really need this to work :slight_smile:

My output:

PLAY [test thing] **************************************************************

TASK [myrole : print the thing] ************************************************
ok: [localhost] => {
“msg”: “Print the var var1”
}

TASK [myrole : print the other thing (should skip)] ****************************
skipping: [localhost]

TASK [myrole : set the other var] **********************************************
ok: [localhost]

TASK [myrole : print the third thing] ******************************************
ok: [localhost] => {
“msg”: “Print the third var var3”
}

PLAY [test thing] **************************************************************

TASK [myrole : print the thing] ************************************************
ok: [localhost] => {
“msg”: “Print the var var1”
}

TASK [myrole : print the other thing (should skip)] ****************************
skipping: [localhost]

TASK [myrole : set the other var] **********************************************
ok: [localhost]

TASK [myrole : print the third thing] ******************************************
ok: [localhost] => {
“msg”: “Print the third var var3”
}

PLAY [test thing] **************************************************************

TASK [myrole : print the thing] ************************************************
ok: [localhost] => {
“msg”: “Print the var var1”
}

TASK [myrole : print the other thing (should skip)] ****************************
skipping: [localhost]

TASK [myrole : set the other var] **********************************************
ok: [localhost]

TASK [myrole : print the third thing] ******************************************
ok: [localhost] => {
“msg”: “Print the third var var3”
}

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

6

I managed to at least get around the error:
The trick is to use “internal” variables inside the role which never get set outside the role. So if I have 2 “external” vars where the role wiill set some 3rd variable depending on those two, the trick is to not re-use the name of one of the two “external” ones. I’ve posted a working example of this here:

https://drive.google.com/file/d/0B81YECbGAyfWaW5rbVRQNlpQT2c/view?usp=sharing

It’s a little bit of extra work really having to watch out for this but at least I got it working. I’d still consider it a bug tho.

7

The section about roles in the ‘Ansible: Up and Running’ book covers this topic quite well.
The recommendation in the book is to always prefix var names inside the role with the name of the role, which I believe is for the exact reason of avoiding the scenario that you ran into.