I installed Ansible using yum on CentOS 6.8 via a corporate mirror of EPEL. However, when I attempted to use the os_server module to interact with the OpenStack API, it failed saying that “shade” is required. When I went to install Shade via Yum, I discovered to my horror and dismay that Shade (python-shade) is not available from EPEL, making it impossible to install via Yum. I attempted to install it via pip but quickly fell into the ninth circle of Python Dependency Hell.
How could Ansible be available via EPEL while not also making available one of the libraries that a module it ships with depends upon? Was this an oversight?
Ansible isn’t responsible for packaging and shipping of the libraries that the
modules may use. Shade isn’t packaged on Centos or EPEL simply because
no one from the community has stepped up to make those packages available.
It is available on Ubuntu and Fedora distributions, but that doesn’t help you
unfortunately.
Installing it via pip was the right thing for you to do in your circumstance, but
I’m curious as the “Python Dependency Hell” you mentioned. Could you elaborate
on that a bit (if nothing else just to satisfy my curiosity)?
The first thing I ran into was a conflict with the installed version of pbr.
To get around this, I set up a virtualenv, and tried installing into that.
I then went down a rabbit hole of dealing with a few dozen transitive dependencies, at least a few of which required me to install gcc in order to install them.
In a few cases, I found that the latest installed version of a transitive dependency depended on a newer version of another library than what was available from the corporate Pypi mirror. I got around these issues by manually specifying older versions of the libraries that had such dependencies.
I managed to get pretty far like this, until pip tried to install cffi, which resulted in a compilation error from gcc:
UnicodeDecodeError: ‘ascii’ codec can’t decode byte 0xe2 in position 75: ordinal not in range(128)
I then tried setting the environment variable LC_ALL=C as I had seen suggested in various places. This resulted in another error:
‘FFI_DEFAULT_ABI’ undeclared
Another Google search later, and I yum installed libffi-devel and tried again. cffi installed successfully.
I then attempted to install shade again. This resulted in dozens of compilation errors from _openssl.c while attempting to transitively install the cryptography library.
I had no idea what to do at this point and gave up.
Yeah, mixing distribution packages with pip packages can get really ugly, especially
as the operating system distribution gets older and package versions get further apart.
I just go pip route when it comes to ansible. Here is my vagrant repo to get you up and running for anyone interested (if nothing else but to cheat off)
I also tried forgoing the virtualenv insanity and just upgrading (via pip) the pbr library in site-packages (which was installed via yum). I was able to upgrade it (to 1.10.0), but when I went to install shade, pip didn’t seem to recognize that pbr had been upgraded (it still gave me the same “pbr>=1.8” dependency failure). I even tried installing pbr 1.8.0 specifically, to no avail.
Could you dump your ~/.bash_history ? I have had to work around this issue too. Perhaps we can find a working solution with help from this mailing list.
Unfortunately, that’s not an option. I’m working on a private network, and that sort of thing would not meet the approval of the Network Nazis.
I can try reproducing the problem at home, though I might not be able to, since it’s a different OS (Ubuntu instead of CentOS) with a different network environment (direct Internet access instead of a corporate enclave).
I also needed to yum install python-importlib, as well as fix the file permissions on the files added by pip to site-packages.
However, now I’m running into a version conflict with the stevedore package. python-keystoneclient wants stevedore >= 1.16.0, but stevedore 1.10+ doesn’t support Python 2.6.
