Problemática con Keystone

Al desplegar un nodo de Controller via Chef nos hemos encontrado con varios problemas. Para empezar, voy a datar la fecha del error. Ayer 11 de Marzo finalicé de actualizar todos los nodos a desplegar, renicié incluso las máquinas y me dispuse a seguir haciendo pruebas de despliegue con los cookbooks actualizados. Pero … empezaron los errores. Por una parte, al hacer pruebas con Quantum necesitaba ver la lista de los tenants y al hacer un listado con “keystone” me dio un error de versionado.

$ keystone
Traceback (most recent call last):
  File "/usr/bin/keystone", line 5, in 
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2807, in 
    parse_requirements(__requires__), Environment()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 594, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: requests>=0.8.8,<1.0

Existe un error documentado al respecto, pero su solución es simple ==> pon la versión del repositorio de Grizzly, que funciona. https://bugs.launchpad.net/ubuntu/+source/python-keystoneclient/+bug/1122146 Bueno pues después de instalar la paquetería del repositorio del Grizzly, siguió sin funcionarme el Keystone así que tuve que buscar alternativas. Volví un paso atrás y quité la paquetería novedosa para volver a la del repositorio oficial de Folsom.

Se ha conseguido modificar al propio Keystone para que las dependencias que solicita, las resuelva a nuestro favor. Viendo el código de Keystone vemos que pide la versión 0.22 del paquete python-keystoneclient que no se encuentra actualmente en Folsom.

root@controller:~# dpkg -l | grep keystone
ii  keystone                         2012.2.1-0ubuntu1.2~cloud0                          OpenStack identity service - Daemons
ii  python-keystone                  2012.2.1-0ubuntu1.2~cloud0                          OpenStack identity service - Python library
ii  python-keystoneclient            1:0.1.3-0ubuntu1.1~cloud0                           Client libary for Openstack Keystone API

Así que cambiaremos el codigo del archivo /usr/bin/keystone:

#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'python-keystoneclient==0.1.3','console_scripts','keystone'
__requires__ = 'python-keystoneclient==0.2.2'
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.exit(
        load_entry_point('python-keystoneclient==0.2.2', 'console_scripts', 'keystone')()
    )

por:

#!/usr/bin/python
# EASY-INSTALL-ENTRY-SCRIPT: 'python-keystoneclient==0.1.3','console_scripts','keystone'
__requires__ = 'python-keystoneclient==0.1.3'
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.exit(
        load_entry_point('python-keystoneclient==0.1.3', 'console_scripts', 'keystone')()
    )

A partir de ese momento ya es posible utilizar keystone de manera habitual.

root@controller:~# keystone tenant-list
+----------------------------------+---------+---------+
|                id                |   name  | enabled |
+----------------------------------+---------+---------+
| 3ef73e7a7ec84f02bec118bfb5644d67 | service |   true  |
| 45d2324cb25b4b38bbda09dffb027662 |  admin  |   true  |
+----------------------------------+---------+---------+

Problemática con MySQL

Bien, el otro problema que nos hemos encontrado es que hemos actualizado los clientes de MySQL y de repente TODOS los servicios de la plataforma han comenzado a perder el acceso a la Base de Datos. En nuestra instalación se ha configurado a MySQL para que permita el acceso remoto al usuario root y al hacer las comprobaciones desde cada uno de los nodos externos al Controller (Network, Storage y Cómputos) ha comenzado a rechazar las conexiones.

Después de mucho investigar se ha tenido que realizar un RollBack hacia la versión anterior de MySQL, tanto del cliente como del Servidor en el nodo de controller. Para poder instalar una versión anterior hemos tenido que usar madison y seleccionar la anterior versión que teníamos en el nodo de Controller.

root@controller:/etc/apparmor.d# apt-cache madison mysql-server-5.5
mysql-server-5.5 | 5.5.29-0ubuntu0.12.04.2 | http://es.archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
mysql-server-5.5 | 5.5.29-0ubuntu0.12.04.1 | http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
mysql-server-5.5 | 5.5.22-0ubuntu1 | http://es.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
 mysql-5.5 | 5.5.22-0ubuntu1 | http://es.archive.ubuntu.com/ubuntu/ precise/main Sources
 mysql-5.5 | 5.5.29-0ubuntu0.12.04.2 | http://es.archive.ubuntu.com/ubuntu/ precise-updates/main Sources
 mysql-5.5 | 5.5.29-0ubuntu0.12.04.1 | http://security.ubuntu.com/ubuntu/ precise-security/main Sources

Ahora procedemos a la instalación de la paquetería con la versión que hemos seleccionado:

apt-get install --reinstall mysql-server-5.5=5.5.22-0ubuntu1 mysql-server-core-5.5=5.5.22-0ubuntu1 mysql-client-5.5=5.5.22-0ubuntu1 mysql-client-core-5.5=5.5.22-0ubuntu1 libmysqlclient18=5.5.22-0ubuntu1 mysql-common=5.5.22-0ubuntu1

Error al generar el fichero de INITCTL de MySQL

Cuando parecía que deberíamos tener ya acceso a levantar el servicio de Base de Datos, nos encontramos con el siguiente error al arrancar:

start: Job failed to start

Ha hecho falta copiar de manera manual el archivo /etc/init/mysql.conf para que el servicio pueda arrancar. Pego el contenido por si fuera de utilidad:

# MySQL Service

description     "MySQL Server"
author          "Mario Limonciello "

start on (net-device-up
          and local-filesystems
      and runlevel [2345])
stop on runlevel [016]

respawn

env HOME=/etc/mysql
umask 007

pre-start script
    #Sanity checks
    [ -r $HOME/my.cnf ]
    [ -d /var/run/mysqld ] || install -m 755 -o mysql -g root -d /var/run/mysqld
    # Load AppArmor profile
    if aa-status --enabled 2>/dev/null; then
        apparmor_parser -r /etc/apparmor.d/usr.sbin.mysqld || true
    fi
    LC_ALL=C BLOCKSIZE= df --portability /var/lib/mysql/. | tail -n 1 | awk '{ exit ($4<4096) }'
end script

exec /usr/sbin/mysqld

post-start script
    for i in `seq 1 30` ; do
        /usr/bin/mysqladmin --defaults-file="${HOME}"/debian.cnf ping && {
            exec "${HOME}"/debian-start
            # should not reach this line
            exit 2
        }
        sleep 1
    done
    exit 1
end script