Weird: Passing variables to roles

[Trond Hindenes]

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?

[Trond Hindenes]

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.

[J Hawkesworth]

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

[Trond Hindenes]

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

[Trond Hindenes]

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 :-)

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   

[Trond Hindenes]

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.

[Christoph Wegener]

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.