ansible-playbook using -i inventory on a playbook fails on pyVmomi not found

Hi:

I have a playbook that uses vmware_guest module to create a new VM on an esxi server. The inventory specified on the command line
does not have localhost defined. I DO specify delegate_to: localhost in the task definition where vmware_guest is used. It fails with the
error message :

module pyVmomi not found

presumably as this module is not found on the esxi server where vmware_guest is being run. pyVmomi IS installed on localhost as reported
by pip show pyVmomi.

ideas??

thx.
Wendell

You’re not delegating properly.

pyVmomi has to be installed on the host you running ansible.

and also make sure pyVmomi is installed for correct version of python used by ansible v2 vs v3, if you have multiple versions installed

running ansible with -v will show you the python used locally, which
applies to localhost if you have not defined it in inventory, if so,
its up to you to define ansible_python_interpreter.

http://docs.ansible.com/ansible/latest/inventory/implicit_localhost.html?highlight=implicit

So, after banging my head around this for 2 days, I gave up and went to the method of using virtualenvs instead.

Tried to install ansible and PyVmomi using pip and it complained about setuptools being out of date. When doing that
upgrade it pooched the whole pip install. pip would not run after - generated an ImportError on sysconfig not found from get_platform.
Apparently a known issue with older (python 2.6) environments. So, looking like I’ll have to go to rhel 7 sooner than we wanted.

Note on the installation error that was initially reported, the problem I believe was that ansible was not installed on our box that
has internet connectivity so when PyVmomi was installed, it got put down into /usr/lib/python2.6/site-packages. However, on the
target system where I was trying to run it from ansible, it was being searched for in /usr/lib/python2.6/site-packages/ansible/modules
and module_utils. So, I suspected you MUST install ansible before installing PyVmomi to get things properly configured in the
python realm.

thx.
Wendell

No, order of installation should not matter, as long as all libraries
are in python's search path during execution.

Well, all I can say is when the ansible task kicked off trying to invoke vmware_guest module, it failed reporting that the
PyVmomi package was not found.

I used strace -f to follow execution of where python was looking for it and it was looking in:

/usr/lib/python2.6/site-packages/ansible/modules and module_utils.

why, I have no clue. the library setting in the ansible setup was default and module location path was reported via -vvv as

/usr/lib/python2.6/site-packages/ansible.

Note that the actual files installed for the PyVmomi package went into:

/usr/lib/python2.6/site-packages

so I suspect that’s why it wasn’t found.

is this configurable somehow?

if looking at the python exeucting ansible-playbook, that is expected,
that is how ansible builds the module code it is going to ship and
execute on the target.

You need to look at the fork invoked when executing the module itself
(which uses it's own python) and does not expect module_utils/modules
but a zipped file (the one compiled in the step above) + the rest of
the PYTHONPATH.

How does one look at the fork involved when executing the module itself to debug it?

The question I guess is how to tell that python instance to ALSO look at:

/usr/lib/python2.6/site-packages

too.

Using -vvv you should see exact python executed for the module, that
should give you an idea of the pythonpath used.

ansible_python_interpreter controls the python used, in case you need
to change it, but also if you really want to strace you can point at a
wrapper script.

another option is using test-module utility in ansible repos
'hacking/' directory

Ya, I’m using the -vvv setting which reports the interpreter being used and the module search path. The module search path just
has /usr/lib/python2.6/site-packages/ansible in it. When explains the behaviour of why it is not finding PyVmomi. Can you just
put a colon list of paths in the library variable in the ansible.cfg to have to like PATH work at the shell?

thx.
Wendell

No, as i said before, the module search path and the module execution
are not directly related, the first is used by ansible to build the
code package it will execute in the end.

The pyvimomi library is requried at execution, not at build time, so
it must be installed so the python invoked at the target can find it.

The pyvmomi module is invoked and executes on the local Host. It uses their API to talk to esxi. I’ll play with the library ansible.cfg value tomorrow and see if I can adjust where it looks for modules.

pyvimomi is not an ansible module, its a python library some ansible
modules use, ansible.cfg does handle module locations but NOT python
library ones.

Ya, I figured that out. I downgraded the pyvmomi module to 5.5.0.2014.1.1 which supports python 2.6. Installed it
and now I see it being attempted to be loaded. It’s failing on backports/ssl_match_hostname/re.py. For whatever
reason, it is not using the established PYTHONPATH I set for this. I presume that somewhere in the call chain
the core python path is being overridden. I guess it’s time to talk to the vmware guys…

The 2014 package is way too old. You really should use the latest from pip.

Got it working late today. The issue with PyVmomi being reported as not being installed was due to dependencies on
several python packages that were being imported in vmware.py but were not installed along with pyvmomi. These
included:

  • chardet
  • certifi
  • urllib3

I think that the above are dependencies on requests & six, not pyvmomi specifically. These packages were on the
server being tested on and I assumed (incorrectly) that all the dependencies needed were also installed.

I then ran into cert issues when attempting to fire it up but got around that by upgrading to 6.0.0 which supports
certs properly.

VM now being created. way cool :slight_smile:

Figuring how this works under the hood took some hacking…but using the ansible var:

ANSIBLE_KEEP_REMOTE_FILE=1

helped a lot. Then running the explode option to have it dump the vars json stuff into a file
allowed the python child process to be debugged directly. this is how I figured out what the
dependencies missing were.