I’ve been considering Ansible for creating our EC2 instances, and have run into a problem with ansible not finding boto from either the command line or a playbook.
Here’s the command line and response; the playbook is similar:
ansible localhost -m ec2 -a “image=ami-0358ce33 instance_type=t1.micro keypair=myKeypairName group=default wait=true”
localhost | FAILED >> {
“failed”: true,
“msg”: “boto required for this module”
}
I’m running Ansible from an activated virtualenv. Ansible was installed with pip install ansible, and boto’s installed as well in the venv (as well as globally).
If I activate the venv and open a command prompt, I can import boto without any problem, and a boto.connect_ec2() succeeds (there is a ~/.boto config file present). Importing ansible and creating a Runner works succeeds as well. I’m running this on Mac OS X.
As a practical matter for the environments and admin tools I develop, I can’t install Python applications and packages globally; they must be run in a virtual environment. That’s very common usage (our Django and Flask apps are virtualenv aware), and I’m a bit disappointed that I can’t just get Ansible up and running in a virtual environment… it’d be great if that were a bit more obvious in the docs, or there’s a blog post to point this simple usage out.
That being said, Ansible is a breath of fresh air… I’ve already been able to do quite a bit in just a few hours that would’ve taken me days with Chef and Puppet.
On OSX, there are many ways to use Python, and as you try to overwrite the default 2.6 that comes with OSX, things can get messy.
The best way I have found is using brew and pip. You will need to change your PATH so that brew’s install location is before the others, but essentially, it is:
$ brew install python
$ pip install boto --upgrade
FWIW, I have boto installed globally using pip:
sudo pip install boto
I can import boto into python without issue, but I get this same error message. I’m using OS X mavericks.
I came across the same issue when I try to run cloudformation module in CentOS in python virtual env. (it used to work some time ago):
(venv)[root@test ansible]# ansible-playbook aws-cf-provision.yml -vv
…
failed: [localhost] => {“failed”: true, “parsed”: false}
failed=True msg=‘boto required for this module’
Traceback (most recent call last):
File “/root/.ansible/tmp/ansible-tmp-1429011194.43-47297413805384/cloudformation”, line 130, in
sys.exit(1)
NameError: name ‘sys’ is not defined
Setting up “export PYTHONPATH=/root/venv/lib/python2.6/site-packages” or “localhost ansible_python_interpreter=/root/venv/bin/python” in hosts makes the original error disappear but the resource doesn’t get created …
This will automatically pick up the active virtualenv’s python interpreter and modules that you’ve installed there, including boto. You don’t need to run any tasks to discover the path to the python interpreter.
I tried a pull request for the GCE modules (as example) to use /usr/bin/env python instead of a fixed /usr/bin/python but that was dismissed without real consideration of whether it actually be a good idea (or not) nor a detailed explanation as to why it was considered “bad”.
I don’t see why, when /usr/bin/env python will mostly be the correct python, it’s still being enforced to use /usr/bin/python .
Maybe someone here knows the inner details as to why??
Ansible doesn’t use a fixed /usr/bin/python necessarily. If you set a different python interpreter via your inventory as Justin did here and keep the remotes files, you’ll notice that Ansible has replaced with /usr/bin/python with the python interpreter you have in your inventory.
> I don’t see why, when /usr/bin/env python will mostly be the correct python, it’s still being enforced to use /usr/bin/python .