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

Problemática

Nos hemos mudado a una nueva oficina y tenemos la suerte de haber contratado ONO 100 MB. La verdad que como línea de comunicaciones es excepcional. Pero mientras trabajamos nos hemos encontrado con un problemilla de comunicaciones a la hora de mantener las sesiones SSH activas.

Como casi todas las empresas TIC, nosotros tenenos servidores externos para varios usos. El caso es que el equipo de Sistemas suele tener varias “consolas” abiertas con múltiples conexiones SSH.

Antes de tener contratado ONO la verdad que no se nos cortaba la conexión de dichas sesiones, pero ahora mismo no podemos dejarlas sin actividad más de unos pocos minutos. Para poder mantener las sesiones abiertas deberemos realizar algunos cambios o bien en la parte del Server o bien en la parte de Cliente.

Chef: Logs después de realizar un BootStrap

Ya hemos visto en post anteriores como realizar la instalación de OpenStack bien con un servidor de [Chef Hosted] bien con un servidor [Chef Privado]. También se realizó un post sobre la instalación de un Servidor de Chef Privado a través de una gema de Ruby knife-server.

Bien, a la hora de depurar errores en cada ejecución del cliente de Chef la salida está configurada por defecto para que lo haga en STDOUT. Sin embargo en las instalaciones por paquetería de chef-client esta configuración se sobreescribe con el valor que se especifique en /etc/default/chef-client, que en nuestro caso será /var/log/chef/chef-client.log.

Valores por paquetería de /etc/chef/clint.rb

log_level          :info
log_location       STDOUT

Valores por paquetería de /etc/default/chef-client

LOGFILE=/var/log/chef/client.log
CONFIG=/etc/chef/client.rb
INTERVAL=1800
SPLAY=20

Eligiendo Servidor

Como ya vimos en el post previo a este, hay una manera muy sencilla de instalar un servidor de Chef mediante una Gema de Ruby, knife-server.

Ver: http://pedrojimenez.github.com/blog/2013/01/29/installing-a-private-chef-server-via-knife-server

Nuestro objetivo real ahora mismo es realizar el despliegue de OpenStack, por tanto cada cual deberá decidir cómo quiere instalarse el servidor propio de Chef. Si es necesaria más información, se puede revisar la documentación oficial de la gente de OpsCode.

Instalación: http://private-chef-docs.opscode.com/installation.html

Existen varias maneras de instalar un servidor de Chef privado, bien sea en una máquina virtual o física. Vamos a abordar una de ellas, la instalación del servidor de Chef via la gema de “knife-server”.

Más información sobre instalaciones manuales de CHEF: http://wiki.opscode.com/display/chef/Installing+Chef+Server+Manually

Será necesario tener un entorno RVM operativo y funcional. Para más información se puede ampliar desde aquí: https://rvm.io/rvm/install/. La verdad que no es el objetivo de este post explicar la instalación de dicho entorno.

¿ Quiénes son ?

Hemos de detenernos un instante para hacer meción especial a las 2 maravillosas gemas que nos harán la vida muy sencilla con OpenStack. Hablamos de “librarian” y de “spiceweasel”. Para que la presentación sea bastante más oficial debemos considerar que librarian será nuestro “cazador de cookbooks” y que spiceweasel será el que los aplique contra el Servidor de Chef que elijamos, bien sea público o privado. Además SpiceWeasel se encargará de aplicar roles/cookbooks a los nodos directamente. Con esta pequeña “joya” se pueden hacer despliegues verdaderamente veloces.

Librarian

Librarian-Chef is a bundler for infrastructure repositories using Chef. You can use Librarian-Chef to resolve your infrastructure’s cookbook dependencies, fetch them, and install them into your infrastructure repository.

Enlace: https://github.com/applicationsonline/librarian

SpiceWeasel

Provides a CLI tool for generating knife commands to build Chef-managed infrastructure from a simple JSON or YAML file.

Enlace: http://wiki.opscode.com/display/chef/Spiceweasel

Después de tener la infraestructura completa y funcional, nos encontramos ayer con un extraño error que no nos permitía el uso de Glance para poder hacer un “upload” de las imágenes. Nos encontramos con un error de dependencias en uno de los paquetes necesarios en la invocación de Glance.

Buscando algo más de información vemos que con la paquetería actual se llega a un error de versionado en el paquete python-keystoneclient y no permite que glance se ejecute.

root@controller:~# glance index
Traceback (most recent call last):
File "/usr/bin/glance", line 5, in 
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2711, in 
parse_requirements(__requires__), Environment()
 File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: python-keystoneclient>=0.1.2,<0.2
          
root@controller:~# glance image-list
Traceback (most recent call last):
File "/usr/bin/glance", line 5, in 
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2711, in 
parse_requirements(__requires__), Environment()
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: python-keystoneclient>=0.1.2,<0.2

Hemos arrancado por fin nuestro laboratorio completamente con Chef y nos tocaba probar uno de los trucos/habilidades más asombrosas de Knife, BooTstrap.

Gracias a este comando podremos incluir a un nodo que no estuviera dado de alta en nuestra infraestructura desde alguno de los nodos de “administración”, completando su registro e instalando el software de Chef en dicho nodo. Además crea el fichero de configuración “client.rb” y los dos ficheros de claves, el de cliente (client.pem) y el del servidor (validation.pem) en el nodo.

[ coruscant:~ ] knife bootstrap 192.168.1.242 -x operador -P onetimepassword --sudo
Bootstrapping Chef on 192.168.1.242
192.168.1.242 [Tue, 11 Dec 2012 15:14:48 +0100] INFO: *** Chef 10.14.4 ***
192.168.1.242 [Tue, 11 Dec 2012 15:14:49 +0100] INFO: Client key /etc/chef/client.pem is not present - registering
192.168.1.242 [Tue, 11 Dec 2012 15:14:49 +0100] INFO: HTTP Request Returned 404 Not Found: Cannot load node compute02
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Setting the run_list to [] from JSON
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Run List is []
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Run List expands to []
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Starting Chef Run for compute02
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Running start handlers
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Start handlers complete.
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Loading cookbooks []
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] WARN: Node compute02 has an empty run list.
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Chef Run complete in 0.632681 seconds
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Running report handlers
192.168.1.242 [Tue, 11 Dec 2012 15:14:50 +0100] INFO: Report handlers complete

Estamos inmersos en la automatización de las instalaciones de Openstack con Chef. Utilizamos actualmente una infraestructura muy sencilla con un Chef-Server local que vamos utilizando para diferentes clientes/laboratorios.

Una de las varias modificaciones que hemos tenido que realizar ha sido con el cookbook de Cinder. Nos hemos encontrado que después de tocar atributos en el “Rol” y el “Entorno” nos seguía dando error al crear el volumen desde consola. Más específicamente un error de iSCSI:

2012-12-05 17:01:19 4046 ERROR cinder.openstack.common.rpc.amqp [-] Exception during message handling
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp Traceback (most recent call last):
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp   File "/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/amqp.py", line 276, in _process_data
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp     rval = self.proxy.dispatch(ctxt, version, method, **args)
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp   File "/usr/lib/python2.7/dist-packages/cinder/openstack/common/rpc/dispatcher.py", line 145, in dispatch
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp     return getattr(proxyobj, method)(ctxt, **kwargs)
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp   File "/usr/lib/python2.7/dist-packages/cinder/volume/manager.py", line 163, in create_volume
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp     volume_ref['id'], {'status': 'error'})
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp   File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp     self.gen.next()
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp   File "/usr/lib/python2.7/dist-packages/cinder/volume/manager.py", line 156, in create_volume
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp     model_update = self.driver.create_export(context, volume_ref)
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp   File "/usr/lib/python2.7/dist-packages/cinder/volume/driver.py", line 437, in create_export
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp     volume_path)
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp   File "/usr/lib/python2.7/dist-packages/cinder/volume/iscsi.py", line 145, in create_iscsi_target
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp     raise exception.ISCSITargetCreateFailed(volume_id=vol_id)
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp ISCSITargetCreateFailed: Failed to create iscsi target for volume volume-4e680c7b-b8f4-43b8-a766-1996a2537474.
2012-12-05 17:01:19 4046 TRACE cinder.openstack.common.rpc.amqp 

Después de darle muchas vueltas al asunto, el comodín que se utilizaba en Mysql 5.1 (versión usada Diablo and Essex) el conocido “%” ha comenzado a fallar. Nos encontramos con errores de acceso a las Bases de Datos que eran nuevos para mi hasta el momento. Revisando las bitácoras de instalaciones previas hemos visto que los permisos de acceso a las diferentes DataBases de Mysql han cambiado y se utiliza como única línea de permisos la siguiente:

mysql_database_user[keystone]: granting access with statement [GRANT all ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'onetimepassword']

Pero solamente con esta sentencia constatamos que el acceso desde otros nodos (multihost) nos daba error. Para solucionar estos problemas se ha probado a añadir sentencias extras de “GRANT” hasta que permitió dichas conexiones. Haciendo un resumen de todas ellas se ha modificado el cookbook de osops-utils para que añada una nueva sentencia de GRANT contra la dirección en la que se bindea el servicio de Mysql. De esta manera se podrá configurar el servicio de Base de Datos en HA y tener los accesos contra la “bind_address”.

Archivo "osops-utils/libraries/database.rb"

        mysql_database_user username do
          connection connection_info
          password pw
          database_name db_name
          host "#{mysql_info["bind_address"]}"
          privileges [:all]
          action :grant
        end

Se ha hecho un Pull Request a la gente de Rcbops con esta modificación.Enlace.

Ahora mismo lo estoy usando en nuestro Chef Server en el despligue de Folsom y funciona “like a charm”. Nos genera dos sentencias de permisos para cada servicio (keystone/glance/nova/horizon).

INFO: Processing mysql_database_user[keystone] action grant (keystone::server line 24)
INFO: mysql_database_user[keystone]: granting access with statement [GRANT all ON keystone.* TO 'keystone'@'%' IDENTIFIED BY 'onetimepassword']
INFO: Processing mysql_database_user[keystone] action grant (keystone::server line 32)
INFO: mysql_database_user[keystone]: granting access with statement [GRANT all ON keystone.* TO 'keystone'@'172.16.172.4' IDENTIFIED BY 'onetimepassword']