# azure\_rm\_virtualmachine tags weirdness

**URL:** <https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167>\
**Category:** Ansible Project\
**Tags:** azure\
**Created:** [April 7, 2017, 1:02am UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167 "2017-04-07T01:02:47Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkporwit](https://avatars.discourse-cdn.com/v4/letter/m/d2c977/32.png) [@mkporwit](https://forum.ansible.com/u/mkporwit)\
**Post date:** [April 7, 2017, 1:02am UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/1 "2017-04-07T01:02:47Z")

</div>

Hi,

Not sure yet if what I have here is a bug or not, so thought I’d ask first. I’m seeing a strange failure out of azure\_rm\_virtualmachine in the latest ansible devel. The working playbook looks as follows:

- name: Create VM and attach NIC  
azure\_rm\_virtualmachine:  
resource\_group: ‘{{ rg }}’  
name: ‘{{service\_name}}-vm-{{item}}’  
network\_interface\_names: ‘{{service\_name}}-vm-{{item}}-nic’  
storage\_account: ‘{{ env\_name }}’  
vm\_size: Standard\_DS1\_v2  
admin\_username: hoylu  
ssh\_password\_enabled: False  
ssh\_public\_keys: ‘{{ssh\_keys}}’  
image:  
offer: UbuntuServer  
publisher: Canonical  
sku: ‘16.04-LTS’  
version: latest  
tags:  
env: ‘{{env}}’  
service: ‘{{service}}’  
with\_sequence:  
start=1  
end=‘{{count}}’  
stride=1  
format=%02d

This code runs. When I then change the tags: section of the playbook task to a dictionary that looks like the following:  
tags: ‘{{ { “env”: env, service: env } }}’

I get an error that looks like this:

“module\_stderr”: “Traceback (most recent call last):\n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_GI\_w3r/ansible\_module\_azure\_rm\_virtualmachine.py", line 1311, in \n main()\n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_GI\_w3r/ansible\_module\_azure\_rm\_virtualmachine.py", line 1308, in main\n AzureRMVirtualMachine()\n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_GI\_w3r/ansible\_module\_azure\_rm\_virtualmachine.py", line 554, in **init** \n supports\_check\_mode=True)\n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_GI\_w3r/ansible\_modlib.zip/ansible/module\_utils/azure\_rm\_common.py", line 197, in **init** \n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_GI\_w3r/ansible\_module\_azure\_rm\_virtualmachine.py", line 797, in exec\_module\n vm\_id=vm\_dict[‘properties’][‘vmId’],\nKeyError: ‘vmId’\n”,

This error only happens with the azure\_rm\_virtualmachine module. The azure\_rm\_publicipaddress and azure\_rm\_networkinterface modules are both fine with that change. Is there some vagary of azure I’m not aware of that’s biting me here, or does this look like a bug to folks?

Thanks,

Marcin

---

<div class="post-metadata">

**Author:** ![j.r.hawkesworth](https://avatars.discourse-cdn.com/v4/letter/j/a3d4f5/32.png) [@j.r.hawkesworth](https://forum.ansible.com/u/j.r.hawkesworth)\
**Post date:** [April 7, 2017, 6:51pm UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/2 "2017-04-07T18:51:18Z")

</div>

I’d suggest double checking that you have the same versions of the azure pip module that the documents say is required.

I’m guessing the error

vm\_id=vm\_dict[‘properties’][‘vmId’],\nKeyError: ‘vmId’\n"

means its looking for something called vmId and not finding it.

I’m not familiar with the azure stuff unfortunately.

Hope this helps,

Jon

---

<div class="post-metadata">

**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\
**Post date:** [April 7, 2017, 10:31pm UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/3 "2017-04-07T22:31:04Z")

</div>

Hrm, kinda looks like a templating bug (or a bad template value)- pretty sure it’s not a module bug since it’s working with the discrete dict.

Can you run that both ways in check\_mode with -vv and look at the tags element in the invocation value from the result to see if it looks the same in both cases? If it works with the discrete dict and fails with the templated one, I’m guessing that the templated arg isn’t getting rendered in the right shape to the module.

-Matt

---

<div class="post-metadata">

**Author:** ![mkporwit](https://avatars.discourse-cdn.com/v4/letter/m/d2c977/32.png) [@mkporwit](https://forum.ansible.com/u/mkporwit)\
**Post date:** [April 8, 2017, 12:27am UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/4 "2017-04-08T00:27:27Z")

</div>

Hi Matt,

Tried what you suggested. Here’s what I get for azure\_rm\_publicipaddress, which works in both instances. Both tasks are in the same playbook, so they’re executed one right after the other with the same args.

1. discrete tags dict: “tags”: {“env”: “dev”, “service”: “foo”}
2. templated tags: “tags”: {“env”: “dev”, “foo”: “dev”}

For azure\_rm\_virtualmachine, which breaks with templated:

1. discrete tags dict: “tags”: {“env”: “dev”, “service”: “foo”}
2. templated tags: blew up, -vv does not show what it tried to send

Running with -vvv, I get the following:

ASK [Create VM and attach NIC] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
task path: /Users/mkporwit/work/infra/ansible/azure/create\_vm.yml:46  
Using module file /usr/local/lib/python2.7/site-packages/ansible-2.4.0-py2.7.egg/ansible/modules/cloud/azure/azure\_rm\_virtualmachine.py  
\<127.0.0.1\> ESTABLISH LOCAL CONNECTION FOR USER: mkporwit  
\<127.0.0.1\> EXEC /bin/sh -c ‘echo ~ && sleep 0’  
\<127.0.0.1\> EXEC /bin/sh -c ‘( umask 77 && mkdir -p “`echo /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610965.68-33490890086942`” && echo ansible-tmp-1491610965.68-33490890086942=“`echo /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610965.68-33490890086942`” ) && sleep 0’  
\<127.0.0.1\> PUT /var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/tmpnQtd7v TO /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610965.68-33490890086942/azure\_rm\_virtualmachine.py  
\<127.0.0.1\> EXEC /bin/sh -c ‘chmod u+x /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610965.68-33490890086942/ /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610965.68-33490890086942/azure\_rm\_virtualmachine.py && sleep 0’  
\<127.0.0.1\> EXEC /bin/sh -c ‘/usr/local/opt/python/bin/python2.7 /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610965.68-33490890086942/azure\_rm\_virtualmachine.py; rm -rf “/Users/mkporwit/.ansible/tmp/ansible-tmp-1491610965.68-33490890086942/” \> /dev/null 2\>&1 && sleep 0’  
The full traceback is:  
Traceback (most recent call last):  
File “/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_module\_azure\_rm\_virtualmachine.py”, line 1310, in   
main()  
File “/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_module\_azure\_rm\_virtualmachine.py”, line 1307, in main  
AzureRMVirtualMachine()  
File “/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_module\_azure\_rm\_virtualmachine.py”, line 554, in **init**  
supports\_check\_mode=True)  
File “/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_modlib.zip/ansible/module\_utils/azure\_rm\_common.py”, line 197, in **init**  
File “/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_module\_azure\_rm\_virtualmachine.py”, line 796, in exec\_module  
vm\_id=vm\_dict[‘properties’][‘vmId’],  
KeyError: ‘vmId’  
failed: [localhost] (item=01) =\> {  
“failed”: true,  
“item”: “01”,  
“module\_stderr”: “Traceback (most recent call last):\n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_module\_azure\_rm\_virtualmachine.py", line 1310, in \n main()\n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_module\_azure\_rm\_virtualmachine.py", line 1307, in main\n AzureRMVirtualMachine()\n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_module\_azure\_rm\_virtualmachine.py", line 554, in **init** \n supports\_check\_mode=True)\n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_modlib.zip/ansible/module\_utils/azure\_rm\_common.py", line 197, in **init** \n File "/var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/ansible\_24PReY/ansible\_module\_azure\_rm\_virtualmachine.py", line 796, in exec\_module\n vm\_id=vm\_dict[‘properties’][‘vmId’],\nKeyError: ‘vmId’\n”,  
“module\_stdout”: “”,  
“msg”: “MODULE FAILURE”,  
“rc”: 0  
}  
to retry, use: --limit @/Users/mkporwit/work/infra/ansible/azure/create\_vm.retry

I don’t think this show any more additional information. What stumps me is why this same templating would be OK for other resources, but not azure\_rm\_virtualmachine. That’s what makes me think this might be a bug. I can create such a tag manually in the azure portal, so I’m pretty sure the key=value pair I’m trying to set is acceptable to azure.

---

<div class="post-metadata">

**Author:** ![mkporwit](https://avatars.discourse-cdn.com/v4/letter/m/d2c977/32.png) [@mkporwit](https://forum.ansible.com/u/mkporwit)\
**Post date:** [April 8, 2017, 12:45am UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/5 "2017-04-08T00:45:16Z")

</div>

Here’s the -vvv output for a working templated invocation of azure\_rm\_publicipaddress. You’ll see the invocation params happily take the templated tags, and see in the state block that they were applied correctly.

TASK [Create public ip for vm] \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*  
task path: /Users/mkporwit/work/infra/ansible/azure/create\_vm.yml:14  
Using module file /usr/local/lib/python2.7/site-packages/ansible-2.4.0-py2.7.egg/ansible/modules/cloud/azure/azure\_rm\_publicipaddress.py  
\<127.0.0.1\> ESTABLISH LOCAL CONNECTION FOR USER: mkporwit  
\<127.0.0.1\> EXEC /bin/sh -c ‘echo ~ && sleep 0’  
\<127.0.0.1\> EXEC /bin/sh -c ‘( umask 77 && mkdir -p “`echo /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610957.8-260047672053181`” && echo ansible-tmp-1491610957.8-260047672053181=“`echo /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610957.8-260047672053181`” ) && sleep 0’  
\<127.0.0.1\> PUT /var/folders/06/zm5r71tj60b4\_19wlz7h822m0000gn/T/tmpMIvukr TO /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610957.8-260047672053181/azure\_rm\_publicipaddress.py  
\<127.0.0.1\> EXEC /bin/sh -c ‘chmod u+x /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610957.8-260047672053181/ /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610957.8-260047672053181/azure\_rm\_publicipaddress.py && sleep 0’  
\<127.0.0.1\> EXEC /bin/sh -c ‘/usr/local/opt/python/bin/python2.7 /Users/mkporwit/.ansible/tmp/ansible-tmp-1491610957.8-260047672053181/azure\_rm\_publicipaddress.py; rm -rf “/Users/mkporwit/.ansible/tmp/ansible-tmp-1491610957.8-260047672053181/” \> /dev/null 2\>&1 && sleep 0’  
ok: [localhost] =\> (item=01) =\> {  
“changed”: false,  
“invocation”: {  
“module\_args”: {  
“ad\_user”: null,  
“allocation\_method”: “Static”,  
“append\_tags”: true,  
“client\_id”: null,  
“domain\_name”: “hoyludevmkp-foo-vm-01”,  
“domain\_name\_label”: “hoyludevmkp-foo-vm-01”,  
“location”: null,  
“name”: “hoyludevmkp-foo-vm-01-ip”,  
“password”: null,  
“profile”: null,  
“resource\_group”: “hoylu-dev-mkp”,  
“secret”: null,  
“state”: “present”,  
“subscription\_id”: null,  
“tags”: {  
“env”: “dev”,  
“foo”: “dev”  
},  
“tenant”: null  
}  
},  
“item”: “01”,  
“state”: {  
“dns\_settings”: {  
“domain\_name\_label”: “hoyludevmkp-foo-vm-01”,  
“fqdn”: “[hoyludevmkp-foo-vm-01.westus2.cloudapp.azure.com](http://hoyludevmkp-foo-vm-01.westus2.cloudapp.azure.com)”,  
“reverse\_fqdn”: null  
},  
“etag”: “W/"7c3db6aa-7057-49c2-8cf4-7c5b0b03e88e"”,  
“idle\_timeout\_in\_minutes”: 4,  
“ip\_address”: “52.183.90.100”,  
“location”: “westus2”,  
“name”: “hoyludevmkp-foo-vm-01-ip”,  
“provisioning\_state”: “Succeeded”,  
“public\_ip\_allocation\_method”: “Static”,  
“tags”: {  
“env”: “dev”,  
“foo”: “dev”  
},  
“type”: “Microsoft.Network/publicIPAddresses”  
}  
}

---

<div class="post-metadata">

**Author:** ![mkporwit](https://avatars.discourse-cdn.com/v4/letter/m/d2c977/32.png) [@mkporwit](https://forum.ansible.com/u/mkporwit)\
**Post date:** [April 8, 2017, 5:59am UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/6 "2017-04-08T05:59:22Z")

</div>

So, here’s the kicker…

Switched from devel to stable-2.3, and I’m able to provision using the templated tags. Switch back to devel, and I’m still able to use the templated mechanism.

So, probably not a bug. Rather, some edge case interplay between the various python dependencies?

---

<div class="post-metadata">

**Author:** ![Matt\_Davis](https://avatars.discourse-cdn.com/v4/letter/m/ce7236/32.png) [@Matt\_Davis](https://forum.ansible.com/u/Matt_Davis)\
**Post date:** [April 11, 2017, 11:13pm UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/7 "2017-04-11T23:13:49Z")

</div>

Possibly- if you’re running from source, make sure you’re running the hacking/env-setup script each and every time you pull new changes in. Otherwise there can be stale .pyc files and other things laying around that can wreak all sorts of havoc (the script cleans all that up).

---

<div class="post-metadata">

**Author:** ![Bjorn\_Hansen](https://avatars.discourse-cdn.com/v4/letter/b/7ba0ec/32.png) [@Bjorn\_Hansen](https://forum.ansible.com/u/Bjorn_Hansen)\
**Post date:** [April 19, 2017, 8:20pm UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/8 "2017-04-19T20:20:08Z")

</div>

As it turns out, this seems to have more to do with the fact that VM updates don’t seem to work. I was able to repro this with a simpler playbook that had nothing to do with the templating:

[https://github.com/ansible/ansible/issues/23765](https://github.com/ansible/ansible/issues/23765)

and found a similar issue([https://github.com/ansible/ansible/issues/20444](https://github.com/ansible/ansible/issues/20444)), which actually already has a fix ([https://github.com/ansible/ansible/pull/22974](https://github.com/ansible/ansible/pull/22974)), it just hasn’t been merged yet. Applying that fix makes the tag issue go away as well. It’s a very simple fix, so it would be nice if it could get merged.

thanks,  
Bjørn

---

<div class="post-metadata">

**Author:** ![mkporwit](https://avatars.discourse-cdn.com/v4/letter/m/d2c977/32.png) [@mkporwit](https://forum.ansible.com/u/mkporwit)\
**Post date:** [April 20, 2017, 10:53am UTC](https://forum.ansible.com/t/azure-rm-virtualmachine-tags-weirdness/24167/9 "2017-04-20T10:53:08Z")

</div>

The same vmId error came back when we tried some more tags-related things. Not sure why tags tickle it, but it seems there’s an issue with how ansible calls the azure SDK ([https://github.com/ansible/ansible/pull/22974](https://github.com/ansible/ansible/pull/22974)). We can confirm that merging this fix resolves the issues we’re having in devel and stable-2.3, and does not appear to introduce any new issues. Hope it gets picked up for a merge into 2.3 final…
