When Monty Taylor and company looked to update the Ansible support for OpenStack, they realized that there was a neat little library waiting to emerge: Shade. Pulling the duplicated code into Shade brought along all of the benefits that a good refactoring can accomplish: fewer cut and paste errors, common things work in common ways, and so on. However, this means that the OpenStack modules are now dependent on a remote library being installed on the managed system. And we do not yet package Shade as part of OSP or the Ansible products. If you do want to use the OpenStack modules for Ansible, here is the “closest to supported” way you can do so.
The Shade library does not attempt to replace the functionality of the python-*client libraries provided by upstream OpenStack, but instead uses them to do work. Shade is thus more of a workflow coordinator between the clients. Thus, it should not surprise you to find that shade required such libraries as keystoneauth1 and python-keystoneclient. In an OSP12 deployment, these can be found in the rhel-7-server-openstack-12-rpms repository. Thus, as a prerequisite, you need to have this repository enabled for the host where you plan on running the playbooks. If you are setting up a jumphost for this, that jumphost should be running RHEL 7.3, as that has the appropriate versions of all the other required RPMs as well. I tried this on a RHEL 7.4 system, and it turns out it has too late a version of python-urllib3.
Let me be clear that these are not supported packages yet. This is just a workaround to get them installed via RPMs. This is a slightly better solution than using PIP to install and manage your Shade deployment, as some others have suggested. It keeps the set of python code you are running tracked via the RPM database. When a supported version of shade is provided, it should replace the version you install from the above links.