Depurando el comportamiento de Keystone para solventar un error que me trae de cabeza en Glance, he visto que un nuevos comandos que se han añadido al servicio de Identidad en OpenStack (“keystone user-role-list”). Este comando nos permitirá extraer un listado de los usuarios/roles/tenants de un solo vistazo.

Problema: que ahora mismo no funciona como se espera. Tan solo muestra el listado de los roles que hay para el usurio que tenemos en las variables de entorno (cargadas en el fichero novarc o como queramos llamarlo). Necesitaba conocer dicho listado del usuario “glance” no del usuario “admin”. En una primera pasada vemos que el listado solamente nos permite obtener los del mismo usuario “admin”:

keystone role-list
+----------------------------------+----------------------+
|                id                |         name         |
+----------------------------------+----------------------+
| 06bc817f9b8647d3bb795c6a1107cff3 |    KeystoneAdmin     |
| 1e77a4036d42446aabcfc706759b732d | KeystoneServiceAdmin |
| 25fcba9f9b9a4982a77f70fd2c84fc31 |        admin         |
| 28941e6016ea488cad9e5e55fee7d8aa |        Member        |
+----------------------------------+----------------------+

keystone tenant-list
+----------------------------------+---------+---------+
|                id                |   name  | enabled |
+----------------------------------+---------+---------+
| 15eafea37ce24b42ab60b1fe0f882d98 | service |   true  |
| 18e181671f174cc1bce64e4370eea96a |  admin  |   true  |
+----------------------------------+---------+---------+

keystone user-list
+----------------------------------+------------+---------+-------+
|                id                |    name    | enabled | email |
+----------------------------------+------------+---------+-------+
| 4be33d2e90ad42ce867954b07aa7b908 |   admin    |   true  |       |
| 8c53cdc1f4354e77a8e2abd39728b20d |    nova    |   true  |       |
| bd9e78ff6ca84c7181f3f412a01597ed | monitoring |   true  |       |
| f6b72f21414246d0a924fc883e694f45 |   glance   |   true  |       |
+----------------------------------+------------+---------+-------+

keystone user-role-list
+----------------------------------+----------------------+----------------------------------+----------------------------------+
|                id                |         name         |             user_id              |            tenant_id             |
+----------------------------------+----------------------+----------------------------------+----------------------------------+
| 06bc817f9b8647d3bb795c6a1107cff3 |    KeystoneAdmin     | 4be33d2e90ad42ce867954b07aa7b908 | 18e181671f174cc1bce64e4370eea96a |
| 1e77a4036d42446aabcfc706759b732d | KeystoneServiceAdmin | 4be33d2e90ad42ce867954b07aa7b908 | 18e181671f174cc1bce64e4370eea96a |
| 25fcba9f9b9a4982a77f70fd2c84fc31 |        admin         | 4be33d2e90ad42ce867954b07aa7b908 | 18e181671f174cc1bce64e4370eea96a |
+----------------------------------+----------------------+----------------------------------+----------------------------------+

Pues después de varios intentos con la infraestructura de Folsom, al final en todas ellas he conseguido llegar a este punto de error. Después de leer por ahí, la solución es bastante sencilla y se aplica de manea instantánea sobre línea de comandos.

Este error nos salta cuando tratamos de invocar los comandos de “nova” después de haber generado y cargado las variables de entorno en el fichero novarc (o el nombre que elijamos).

root@controller:~# nova list
Please set a password for your new keyring

Aunque metamos una contraseña, nos seguirá molestando con este error de manera continuada. Para evitarlo basta con añadir la línea de abajo al bashrc del usuario y volver a cargarlo.

Añadimos al /home/user/.bashrc y recargamos
export OS_NO_CACHE=1
source /home/user/.bashrc 

Comprobamos que se ejecutan los comandos de “nova”:

root@controller:/etc/nova# nova volume-list
+--------------------------------------+-----------+-----------------+------+-------------+-------------+
| ID                                   | Status    | Display Name    | Size | Volume Type | Attached to |
+--------------------------------------+-----------+-----------------+------+-------------+-------------+
| 850e5d38-dc87-4267-b3c9-9d02205f11ab | available | MiPrimerVolumen | 3    | None        |             |
+--------------------------------------+-----------+-----------------+------+-------------+-------------+

La segunda opción es ejecutar los comandos de “nova” con la opción –no_cache, aunque sobre el mismo entorno no he sido capaz de que funcione con dichas indicaciones.

root@controller:~# nova --no_cache volume-list

Enlaces:

https://bugs.launchpad.net/python-novaclient/+bug/1020238

https://lists.launchpad.net/openstack/msg16095.html (solución de Vish)

Bueno por fin me he decidido a escribir algo de todo lo que hago y parte de lo que leo. He valorado un montón de opciones previas pero creo que Octopress se adapta perfectamente a mis necesidades. Es por supuesto software libre y como ya hemos visto desplegable dentro de una infraestructura PaaS.

Gracias a @achilued y a @Sfrek por el apoyo y los ánimos. Espero darle la vidilla que se merece ;)