A quick question as I’m slightly knee-deep in troubleshooting an upgrade to Ansible 2.7, but did the way searching for python libraries / site-package directories change, specifically with regard to the Azure cloud modules?
As a quick test, I’m in a virtualenv with Ansible 2.7 installed and ansible[azure] included. If I try to use azure_rm_resourcegroup_facts in a playbook, I get “Do you have packaging installed? Try pip install packaging”
I do have packaging installed, as I can open python REPL and type ‘import packaging’ and see packagine.file pointing to the site-packages under the virtualenv OK.
If I precede running ansible-playbook with PYTHONPATH, e.g. PYTHONPATH=/root/plays/ansible-azure/lib/python2.7/site-packages ansible-playbook test.yml
then the Azure module works fine.
Unfortunately while this might be a quick fix for command line Ansible (declare PYTHONPATH in some shell vars file), the actual problem I need to resolve is inside Ansible Tower and so I’m unclear what I would need to do to make Ansible Tower look in the right place for libraries.
The point of this slightly rambly post is to work out whether this was an unannounced change in module functionality in 2.7 or whether I’ve missed something important off the changelogs and now need to update how python package lookups are handled.
Bit more investigation, looks like this might be an issue with a specific module, so I’ll gather some notes and go raise an issue on Github.
azure_rm_virtualmachine_facts appears to be having the issues. Here’s the output of a simple playbook that uses azure_rm_publicipaddress_facts and azure_rm_virtualmachine_facts - it fails on the virtualmachine facts part.
PLAY [VM Management Role] ******************************************************
TASK [vm.mgmt : Check for Public IP] *******************************************
ok: [rhel01 → localhost]
ok: [rhel02 → localhost]
TASK [vm.mgmt : Override ansible_host with public IP] **************************
ok: [rhel02]
ok: [rhel01]
TASK [vm.mgmt : Show public ip] ************************************************
ok: [rhel02] => {
“msg”: “server ip is x.y.a.b”
}
ok: [rhel01] => {
“msg”: “server ip is x.y.a.b”
}
TASK [vm.mgmt : Get VM detail] *************************************************
fatal: [rhel01]: FAILED! => {“changed”: false, “msg”: “Do you have packaging installed? Try pip install packaging- No module named packaging.version”}
fatal: [rhel02]: FAILED! => {“changed”: false, “msg”: “Do you have packaging installed? Try pip install packaging- No module named packaging.version”}
PLAY RECAP *********************************************************************
rhel01 : ok=3 changed=0 unreachable=0 failed=1
rhel02 : ok=3 changed=0 unreachable=0 failed=1
Ok disregard previous post, I had in fact forgotten to assign a delegate_to: localhost option as I needed to talk to the Azure API from the Ansible Tower server and not the remote VM.
I’ve also confirmed now that everything else I had issues with appears to work fine after switching to the Ansible (not awx) virtualenv and doing a full ‘pip install --upgrade --force-reinstall ansible[azure]’
So now happily working with Ansible 2.7 + Tower 3.3.0 with Azure modules. Hurray!
The exact upgrade path that I found worked was (and this is on a CentOS 7 box, but might be v similar for an Ubuntu)
cd ~awx/venv/ansible
. bin/activate
pip install --upgrade --force-reinstall ansible[azure]
First, I activate the virtualenv that Ansible Tower uses when it fires jobs, as I understand it. This is specific for Ansible Tower, so you might need to adjust where you activate your virtualenv from if you’re just running Ansible from the command line (or even create one, which I’ve decided is probably a good idea for overall system stability, rather than installing a bunch of packages directly into the systems’ python library)
Then I run pip with both the --upgrade and --force-reinstall flags on the ansible[azure] package. Now this worked fine on one dev box that I share with some colleagues, but a different box had some missing core system packages (gcc, libffi-dev, python-dev if I recall) which needed installing. Not sure if that was an edge case or not, it wasn’t a very clean system build so might be a bit of a mess.
After that, jobs using Azure modules continued to work fine including the newer ones, e.g. azure_rm_virtualmachine_facts
As mentioned in an earlier post, I did also have a mistake in my playbook where I was trying to run the azure modules from a target server instead of the ansible server - I wanted to build a fact dictionary that contained the vmSize of various VM’s, and the task ran against my inventory without me adding ‘delegate_to: localhost’ on the task. That caused me to think I still had pip / python issues for a few minutes until I realised what was happening!