Purgar la bitacora del journal

Hace un par de dias note que la computadora donde tengo instalado Fedora 23 se estaba quedando sin espacio en el disco duro. El mayor uso que le daba a esa máquina era para realizar pruebas de proyectos realizados con vagrant, por lo que mi sospecha apuntaba a algún archivo remanente por parte de la aplicación.

Después de analizar posibles causas note que la razón por cual me estaba quedando sin espacio en el disco se debió a que las ejecuciones de vagrant se acumulaban en la era la bitácora del journal. Por lo que era necesario purgar los logs de la bitácora.

Esto se logra a traves del argumento –vacuum-* el cual tiene tres modalidades:

  • Por tamaño(–vacuum-size)
  • Por antigüedad(–vacuum-time)
  • Por archivos(–vacuum-files)

En el siguiente ejemplo, se eliminan todos archivos del journal hasta que el espacio que estos ocupan en el disco llega a ser menor a 100MB.

# journalctl --vacuum-size=100M 

Para eliminar los archivos almacenados que contengan datos anteriores a dos dias a partir de su ejecución seria:

# journalctl --vacuum-time=2d 

Aunque lo mejor es dejar que systemd haga la limpieza por nosotros, esto se puede configurar en el archivo de /etc/systemd/journald.conf especificando un limite con la entrada

SystemMaxUse=100M

Compilación de archivos de Java bajo demanda

fswatch es un comando multiplataforma que monitorea y envia notificaciones cuando el contenido de un archivo cambia. Un ejemplo practico de su uso, es el compilar un archivo en el momento en que este es guardado.

Instalación

En Ubuntu, no existe un paquete oficial que facilite su instalación por lo que es necesario realizar una serie de pasos para generar los paquetes e instalarlos desde código fuente.

$ sudo apt-get install build-essential  -y
$ wget https://github.com/emcrisostomo/fswatch/releases/download/1.9.3/fswatch-1.9.3.tar.gz
$ tar -xvzf fswatch-1.9.3.tar.gz
$ cd fswatch-1.9.3
$ ./configure
$ make
$ sudo make install
$ sudo ldconfig

Uso

Una vez instalado es posible anidarlo a algún evento y realizar una acción especifica. En este caso se realiza una compilación del archivo modificado.

$ fswatch -0 HolaMundo.java | (while read -d "" event; do javac HolaMundo.java; done)

Para mayor información acerca de uso, visite su pagina oficial

Conceptos básicos de Telecomunicaciones

Considero que mis conocimientos técnicos acerca del manejo de telecomunicaciones son muy escasos y en ocasiones bastante ambiguos pero dado mi interés por aprender acerca de Software Defined Network me parece importante comprender los fundamentos.

A continuación enlistare algunos de ellos:

Software Defined Networking (SDN)

Provee un método centralizado y programable para administrar y configurar dispositivos de red físicos y/o virtuales de un centro de datos. Esto se logra debido a la separación de las funciones de control plane (el cual decide como manejar el trafico de paquetes de red) y data plane (el responsable de ejecutar en las decisiones del control plane) en los dispositivos de red. “The Road to SDN: An Intellectual History of Programmable Networks” es un articulo publicado por la universidad de Princeton el cual narra las tecnologías involucradas a lo largo de la historia en el nacimiento de SDN.
Actualmente existen una variedad de proyectos de código abierto relacionados con SDN (algunos de ellos enlistados en Open Source SDN) pero solo un grupo de ellos se encuentran activos por sus comunidades. El reporte de anual de SDxCentral muestra un análisis detallado acerca de los mismos.

Network Virtualization (NV)

La virtualización permite simular una plataforma de hardware por medio del software. Cuando la virtualización es utilizada en los dispositivos de red, es posible tener una simulación de switches, routers, firewalls, etc. Network Virtualization o NV, ofrece la capacidad de crear redes superpuestas y reducir costos mediante la utilización de white boxes o de dispositivos de red genéricos.

Network Function Virtualization (NVF)

Network Virtualization con esteroides. Ofrece una nueva manera de diseñar, desplegar y administrar servicios de red. Desasocia las funciones de red como NATing, Firewalling, Intrusion Detection, Domain Name Service (DNS) y Caching de los dispositivos físicos. Lo cual se traduce en una reducción de hardware de propósito especifico y los costos asociados a su conexión y operación, por medio de aplicaciones de software.
NFV complementa a SDN, sin embargo son conceptos completamente independientes. NFV puede virtualizar y desplegar funciones sin la necesidad de un controlador de SDN y viceversa.
La European Telecommunications Standards Institute (ETSI) publico un articulo introductorio acerca del tema.

Conceptos de OpenStack Networking (Neutron)

La terminología que usa el proyecto de OpenStack Networking (aka. Neutron) puede llegar a confundir a mas de alguno; conceptos como agentes, recursos, extensiones, plugins y drivers en ocasiones son referidos indistintamente. Es por ello que me parece necesario clarificar estos conceptos y proveer información acerca de su uso.

Comenzare con los conceptos relacionados a su arquitectura. El servicio web (RESTful) principal por medio del cual Neutron expone sus capacidades a los usuarios es denominado neutron-server. Este servicio primordialmente tiene dos funcionalidades. La primera, referida como Neutron API, es responsable de procesar peticiones, validar información y restringir accesos. La segunda, Neutron RPC, es responsable de delegar las solicitudes de los usuarios a otros servicios llamados agentes, esta comunicación se realiza mediante una cola de mensajes.

Agentes

Los agentes de Neutron son servicios que escuchan la cola de mensajes y procesan las solicitudes provenientes del neutron-server, ejecutan tareas específicas en la red y por lo general son ubicados en los nodos de computo. En el código fuente, estos pueden ser localizados en la carpeta de neutron/cmd/eventlet/agents y tienen distintas funciones:

  • neutron-dhcp-agent: Encargado de proveer servicios de DHCP a todas las redes.
  • neutron-l3-agent: Responsable de ofrecer servicios de ruteo, nateo(natting), grupo de reglas de seguridad (security-group rules) y asignación de IPs Flotantes.
  • neutron-ns-metadata-proxy: Agrega encabezados de X-Forwarded-For y X-Neutron-Router-ID a las peticiones realizadas por las instancias hacia el servicio de nova-api-metadata que son interceptadas por neutron-metadata-agent.
  • neutron-metadata-agent: Agrega encabezados de X-Instance-ID, X-Tenant-ID y X-Instance-ID-Signature y determina desde que namespace se realizo dicha petición para enviar la respuesta.

Recursos y Extensiones

Ambos terminos se refieren a las entidades que son expuestas en la API y que pueden ser consumidas mediante los verbos HTTP (GET, POST, DELETE, PUT, etc.). Su diferencia radica en la manera en que son registradas en el servicio de neutron-server.
Los Recursos son las entidades que siempre son registradas esto se debe a este registro es realizado por el constructor de la clase RouterAPI. Hoy en dia se cuenta con cuatro clases de recursos: “network”, “subnet”, “subnetpool” y “port”.
Por otro lado, las Extensiones son aquellas entidades que dinámicamente son registradas. Como ejemplo de ello estan los “security groups”. Otros proyectos como lo es neutron-lbaas hacen uso de la función register_resource_by_name para registrar “member”.

Plugins

La API de Neutron tiene la capacidad de extender su funcionalidad mediante la adición de plugins de terceros. Las peticiones validadas por el neutron-server son trasmitidas a los agentes por medio de ellos. Existen dos tipos de plugins:

  • Core Plugin: Implementa las acciones sobre los Recursos “core” (L2 + IPAM). Cabe mencionar que en el release de Havana se libero el Modular Layer 2 (ML2), el cual permite utilizar simultáneamente una variedad de tecnologías de red(por ejemplo, LinuxBridge, Open vSwitch, HyperV) que pueden ser encontradas en los centros de datos.
  • Service Plugin: Provee servicios adicionales de red, como ruteo (routing), balanceo de carga (load balancing), cortafuegos (firewalling) y mas.

Drivers

El concepto de “drivers” fue introducido gracias a la creación del plugin ML2. De acuerdo a su propósito los drivers pueden ser catalogados como:

  • Type Drivers: Cada tipo de red disponible es administrada por un TypeDriver. El cual mantiene el estado, ejecuta una validación  y realiza la asignación de redes. Algunos posibles valores son: local, flat, vlan, gre y vxlan.
    type_drivers = local,flat,vlan,gre,vxlan
    
  • Mechanism Drivers: Se asegura de implementar la información requerida dependiendo del tipo de driver definido. Actualmente soporta acciones de creación, actualización y eliminación de recursos de red y puertos. Algunos posibles valores son: linuxbridge, openvswitch, omniswitch, brocade, cisco_nexus, lenovo, etc.
    mechanism_drivers = openvswitch,
    

OSProfiler

Es una poderosa biblioteca que permite registrar todos los eventos generados por los servicios de OpenStack durante una petición web. Estos eventos pueden ser extraídos en una traza y ser mostrados en un reporte con formato json o html. Lo cual permite encontrar posibles retrasos en la respuesta de los servicios.

Para configurar e instalar sus dependencias en Devstack lo único necesario es  habilitar los siguientes plugins.
Nota: es necesario mantener el orden en el archivo local.conf, en caso contrario fallará el proceso de provisionamiento.

[[local|localrc]]
...
enable_plugin panko https://git.openstack.org/openstack/panko
enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer
enable_plugin osprofiler https://git.openstack.org/openstack/osprofiler
...

Una vez que ./stack.sh haya terminado de provisionar el ambiente de desarrollo, notaremos que en los archivos de configuración de cada uno de los servicios tendrá una nueva sección llama profiler.

...
[profiler]
hmac_keys = SECRET_KEY
trace_sqlalchemy = True
enabled = True
...

En ella el valor asignado a hmac_keys sera la contraseña que nos permitirá activar la acumulación de eventos durante la petición web lanzada desde un cliente. Estos eventos serán recolectados por panko y ceilometer.

En el siguiente ejemplo, se creará una traza a partir de la llamada donde se enlistan los proyectos, cabe notar el uso del argumento –os-profile:

$ openstack project list --os-profile SECRET_KEY
+----------------------------------+--------------------+
| ID                               | Name               |
+----------------------------------+--------------------+
| 1957555a283947a9a8417091ed931f27 | invisible_to_admin |
| 217b12bf7a3d4a958821c4935c65fc6d | alt_demo           |
| 82ce0b2964004c2394e57e9d549bbfb4 | demo               |
| 971237716c31481f8002b0e2d9e80633 | service            |
| fddac1b83ed445eb9ef3c8d3eec23c84 | admin              |
+----------------------------------+--------------------+
Trace ID: ea8e0cf7-f795-4122-8bfc-f67986d9eb75
Display trace with command:
osprofiler trace show --html ea8e0cf7-f795-4122-8bfc-f67986d9eb75 

Nota: En caso de no utilizar panko como servicio de Backend para Ceilometer es necesario especificar la cadena de conexión.

$ openstack project list --os-profile SECRET_KEY --connection-string mongodb://localhost:27017/ceilometer

Por ultimo, y como el comando lo sugiere, para poder visualizar la traza creada es necesario utilizar el cliente de osprofiler, el cual nos generará un reporte.

$ osprofiler trace show --html ea8e0cf7-f795-4122-8bfc-f67986d9eb75 > /var/www/html/index.html

Separación de la nube – Hosts agrupados y Zonas de disponibilidad (Nova)

Estos terminos estan íntimamente ligados, incluso en la manera en que son configurados. Ambos responden a la necesidad de agrupar lógicamente los nodos de computo y se diferencian en el nivel de acceso o visibilidad para cada uno.

Host agrupado

Asociación que ofrece a los administradores de la nube agrupar lógicamente diferentes nodos de computo de tal manera que se facilite algunas tareas para su administración y mantenimiento. Generalmente esta información sirve para la toma de decisiones del nova-scheduler.

A lo largo de este ejemplo, se utilizara un host agrupado llamado SSD_DC_P3608 para representar un grupo de nodos de computo que tengan una característica del disco duro en común.

stack@devstack:~$ openstack aggregate create SSD_DC_P3608
+-------------------+----------------------------+
| Field             | Value                      |
+-------------------+----------------------------+
| availability_zone | None                       |
| created_at        | 2017-01-26T05:30:08.257388 |
| deleted           | False                      |
| deleted_at        | None                       |
| id                | 1                          |
| name              | SSD_DC_P3608               |
| updated_at        | None                       |
+-------------------+----------------------------+

Lo siguiente a realizar es configurar las propiedades que diferenciaran este grupo y seran utilizadas por el servicio de nova-scheduler durante la toma de decisiones. Ademas de agregar el nodo de computo al grupo.

stack@devstack:~$ openstack aggregate set --property ssd=true SSD_DC_P3608
stack@devstack:~$ nova-manage host list
host                            zone           
0.0.0.0                         internal       
devstack                        internal
stack@devstack:~$ openstack aggregate add host SSD_DC_P3608 devstack
+-------------------+----------------------------+
| Field             | Value                      |
+-------------------+----------------------------+
| availability_zone | None                       |
| created_at        | 2017-01-26T05:30:08.000000 |
| deleted           | False                      |
| deleted_at        | None                       |
| hosts             | [u'devstack']              |
| id                | 1                          |
| metadata          | {u'ssd': u'true'}          |
| name              | SSD_DC_P3608               |
| updated_at        | None                       |
+-------------------+----------------------------+

El ultimo paso es asociar la propiedad que diferencia al host agrupado con el tipo de flavor que podría seleccionar el usuario de la nube.

stack@devstack:~$ openstack flavor set m1.tiny --property ssd=true
stack@devstack:~$ openstack flavor show m1.tiny
+----------------------------+------------+
| Field                      | Value      |
+----------------------------+------------+
| OS-FLV-DISABLED:disabled   | False      |
| OS-FLV-EXT-DATA:ephemeral  | 0          |
| access_project_ids         | None       |
| disk                       | 1          |
| id                         | 1          |
| name                       | m1.tiny    |
| os-flavor-access:is_public | True       |
| properties                 | ssd='true' |
| ram                        | 512        |
| rxtx_factor                | 1.0        |
| swap                       |            |
| vcpus                      | 1          |
+----------------------------+------------+

El usuario de la nube no percibira la existencia de host agrupados ni las propiedades definidas en el flavor. Aunque de antemano sabemos que internamente el nova-scheduler a traves del AggregateInstanceExtraSpecsFilter tomara en cuenta la metadata definida el flavor m1.tiny durante la creación de la instancia, y considerara solo los nodos de computo que pertenezcan a el host aggregate SSD_DC_P3608. Nota: AggregateInstanceExtraSpecsFilter (Current Implementation) vs AggregateInstanceTypeFilter (New Implementation).

Zonas de disponibilidad

Perspectiva de OpenStack Compute(Nova)

Este termino refiere al hecho de compartir un host aggregate a los usuarios de la nube para hacer uso de sus características.

stack@devstack:~$ openstack aggregate set --zone fast-io SSD_DC_P3608
stack@devstack:~$ openstack availability zone list
+-----------+-------------+
| Zone Name | Zone Status |
+-----------+-------------+
| internal  | available   |
| fast-io   | available   |
| nova      | available   |
| nova      | available   |
| nova      | available   |
+-----------+-------------+

Por ultimo, cabe mencionar que es posible administrar los host aggregates y zonas de disponibilidad desde la interfaz web. Utilizando las credenciales de administrador en la pestaña de Host Aggregates.

Separación de una nube – Celdas

El Teorema de Brewer afirma que es imposible garantizar la Consistencia(Consistency), Disponibilidad(Availability) y la Tolerancia al Particionado(Partition Tolerance) de datos de manera simultanea en un Sistema Distribuido, de tal forma que solo posible tener alguna combinación de dos características al mismo tiempo.

Celdas

Para permitir el crecimiento horizontal de una nube de manera que pudiese superar los limites impuestos por las Base de Datos Relacionales y/o Message Brokers, el servicio de OpenStack Compute(Nova) propuso el concepto de Celdas, el cual sacrifica la Consistencia de los datos en favor a la Disponibilidad y Tolerancia al Particionado.

Su primera etapa de implementación fue realizada a partir del release de Grizzly. Esta versión carece de documentación y es bastante confusa para en su utilización, es por ello que se creo una segunda versión con un manifiesto y algunas lecciones aprendidas, como lo son:

  • El almacenar los datos en un solo lugar.
  • Contar con solo una forma de instalar o utilizar celdas.
  • Guardar la menor cantidad de información de manera global.

Y aunque su instalación y configuración aun no se encuentran todos los pasos en la documentación oficial, podemos deducir algunos pasos escritos en la biblioteca de Nova para Devstack que son ejecutados al habilitar el servicio de “n-cell”.

local.conf

...
ENABLED_SERVICES+=,n-cell

Belmiro Moreira comparte la arquitectura utilizada por el Conseil Européen pour la Recherche Nucléaire(CERN) en su publicación “CERN Cloud Architecture”.

Cada celda contara con el servicio de nova-cell que utilizara un archivo de configuración en el cual se especificara los valores para la conexión a la Base de Datos y el Message Broker. Para poder identificar cada celda se utilizara un nombre único y el tipo de celda definira el propósito de la misma.

/etc/nova/nova-cells.conf

[DEFAULT]
transport_url = rabbit://stackrabbit:password@host:5672/child_cell
dhcpbridge_flagfile
...
[database]
connection = mysql+pymysql://root:password@host/nova_cell?charset=utf8
...
[cells]
name = child
cell_type = compute
enable = True

En el caso del servicio de nova, este solo utilizara la API como capa intermedia entre las llamadas de los clientes y las celdas.

/etc/nova/nova.conf

...
[cells]
name = region
cell_type = api
enable = True

Por ultimo es necesario crear un esquema de base de datos y establecer la comunicación con el Message Broker. Supongo el iniciar o reiniciar el servicio dependerá en gran medida de la distro que se utilice.

$ nova-manage --config-file /etc/nova/nova-cells.conf db sync
$ nova-manage --config-file $/etc/nova/nova-cells.conf cell create --name=region --cell_type=parent --username=stackrabbit --hostname=host --port=5672 --password=password --virtual_host=/ --woffset=0 --wscale=1
$ nova-manage cell create --name=child --cell_type=child --username=stackrabbit --hostname=host --port=5672 --password=password --virtual_host=child_cell --woffset=0 --wscale=1

Durante el Summit en Austin, Andrew Laski compartió los avances realizados en Celdas V2, este ha sido un esfuerzo continuo a traves de varios releases.

Separación de una nube – Regiones

Existen distintas causas por las que es necesario distribuir la información. Por ejemplo, las normativas de Privacidad y Protección de Datos en la Unión Europea impiden la apropiación, divulgación y comercialización de los datos de los clientes obligando a las organizaciones a almacenar dicha información en el lugar donde se origina. Otro ejemplo es quizá la creación de una aplicación de que sea tolerante a fallos, donde necesite replicar datos entre dos máquinas alojadas en distintas regiones.

Cualquiera que sea, se requiere que los recursos de un centro de datos puedan ser administrados de manera mas flexible sin llegar a ser demasiado determinista, esto es, ofrecer al usuario la capacidad de definir el destino donde cada recurso al ser creado.

Esta serie de artículos pretende mostrar de manera practica, las distintas maneras que OpenStack ofrece para distribuir los recursos, las cuales son:

  • Regiones(Regions)
  • Celdas(Cells)
  • Zonas de disponibilidad(Availability Zones)
  • Host agrupados(Host aggregate)

Regiones

Una región representa una instancia de OpenStack, es decir, un colección de adicional de servicios de OpenStack (Nova, Cinder, Neutron, etc.) generalmente distribuidos en otra zona geográfica. Para lograrlo es necesario realizar una serie de cambios en la configuración de la nube.

El primer cambio permite utilizar la interfaz web para acceder a una lista predefinida de regiones, esta definición solo existe dentro del contexto de la instancia de Horizon por lo que quizá pueda causar algo de confusión en su uso. Su configuración consiste en enlistar los endpoints de Keystone de cada región en una lista de tuplas en el archivo de configuración de la instancia de Horizon. Utilicemos como ejemplo la siguiente configuración:

/etc/openstack-dashboard/local_settings.py

AVAILABLE_REGIONS = [
    ('http://regionuno.ejemplo.com:5000/v2.0', 'RegionUno'),
    ('http://regiondos.ejemplo.com:5000/v2.0', 'RegionDos'),
    ('http://regiontres.ejemplo.com:5000/v2.0', 'RegionTres'),
]

Una vez aplicado el cambio y reiniciado el servicio, la pagina de inicio de sesión tendrá la opción de seleccionar la región a utilizar.

También es posible que con este cambio un usuario que este definido en RegionDos no se encuentre definido en RegionTres ya que sus instancias de Keystone no comparten la misma fuente de datos. Para ello necesitamos modificar la configuración de los servicios de Keystone para que consuma la misma fuente de datos el cual depende de el tipo de driver que utilicemos.

/etc/keystone/keystone.conf

[identity]
# Entry point for the identity backend driver in the `keystone.identity`
# namespace. Keystone provides a `sql` and `ldap` driver. This option is also
# used as the default driver selection (along with the other configuration
# variables in this section) in the event that `[identity]
# domain_specific_drivers_enabled` is enabled, but no applicable domain-
# specific configuration is defined for the domain in question. Unless your
# deployment primarily relies on `ldap` AND is not using domain-specific
# configuration, you should typically leave this set to `sql`. (string value)
driver = sql

[database]
connection = mysql+pymysql://root:password@127.0.0.1/keystone?charset=utf8

Por ultimo es necesario registrar cada servicio con su respectiva región.

...
$ openstack endpoint create --region RegionDos compute --publicurl http://regiondos.ejemplo.com:8774/v2.1 --internalurl http://regiondos.ejemplo.com:8774/v2.1 --adminurl http://regiondos.ejemplo.com:8774/v2.1
...

Horizon detectará este cambio al inicio de la sesión y desplegará esta información en el área que se muestra los distintos proyectos.

multi-region

Como resultado obtenemos una arquitectura compartida lo cual puede tener sus implicaciones a medida que la nube crezca.

Nota: Es posible modificar los valores de la region en devstack aunque he de reconocer que he tenido algunos problemas con el servicio de nova-legacy. En la documentación oficial menciona los valores a configurar en los archivos de configuración.

Devstack – RegionUno

local.conf

...
HOST_IP=10.0.0.3
REGION_NAME=RegionUno
...

Devstack – RegionDos

local.conf

...
disable_service horizon
KEYSTONE_SERVICE_HOST=10.0.0.3
KEYSTONE_AUTH_HOST=10.0.0.3
REGION_NAME=RegionDos
KEYSTONE_REGION_NAME=RegionUno

Utilizando vagrant-libvirt

Dado que recientemente tuve algunos problemas para utilizar VirtualBox, he decidido utilizar un plugin de vagrant para crear maquinas por medio de libvirt. Tratare de cubrir los puntos esenciales de su instalacion y configuracion en una computadora fisica.

Cabe mencionar que es preferible utilizar virtualizacion por hardware(KVM) que emulacion por software(QEMU) dado sus notables ventajas en rendimiento. Para ello es necesario revisar que se nuestro hardware soporte y tenga habilitada dicha caracteristica, esta validacion es diferente entre distintos fabricantes y se realiza a traves de las configuraciones del BIOS.

Como paso inicial es necesario contar con el servicio de libvirtd correctamente instalado y configurado. Ademas, habilitaremos la capacidad de tener virtualizacion anidada en los modulos del kernel. Esta capacidad permite crear maquinas virtuales dentro de otra maquina virtual sin necesidad de emular las caracteristicas del hardware.

Los comandos necesarios para Fedora 23 son:

$ sudo dnf install -y libvirt
$ sudo systemctl enable libvirtd
$ sudo systemctl start libvirtd
$ sudo rmmod kvm-intel
$ sudo sh -c "echo 'options kvm-intel nested=y' >> /etc/modprobe.d/dist.conf"
$ sudo modprobe kvm-intel
$ sudo usermod -a -G libvirt $USER

Una vez que tenemos el servicio de libvirt ejecutandose, los modulos del kernel configurados y nuestro usuario incluido en el grupo de libvirt, procedemos con la instalacion de Vagrant y sus respectivos plugins

$ sudo dnf install -y https://releases.hashicorp.com/vagrant/1.8.1/vagrant_1.8.1_x86_64.rpm
$ sudo dnf install -y gcc
$ vagrant plugin install vagrant-libvirt

Por ultimo y simplemente para validar que todo funcione correctamente, crearemos un Vagrantfile con un Vagrant box que soporte libvirt como proveedor. En el sitio oficial podremos encontrar una gran variedad de ellos.

Para el arranque de la maquina es necesario ejecutar el comando de vagrant up con el argumento de –provider libvirt o declarar la variable de ambiente VAGRANT_DEFAULT_PROVIDER=libvirt que modifica el valor por defecto del proveedor utilizado por vagrant.

$ vagrant init centos/7
$ vagrant up --provider libvirt

Revision de codigo desde la consola

Como parte de mi proceso de iniciacion como desarrollador de OpenStack y a su vez, tratando de entender mas el codigo fuente de distintos proyectos, he estado realizando algunas revisiones de codigo. Esta actividad principalmente se lleva a cabo mediante el portal web. Pero en busca de metodos alternativos en el que pueda ser mas eficiente este proceso me he aventurado a utilizar gertty.

Gertty es basicamente un cliente de consola para realizar revisiones de codigo provistas por un servidor Gerrit. Fue desarrollado y anunciado por la comunidad de OpenStack en Marzo del 2015 y hoy en dia en su version 1.3.2 es utilizado por algunos desarrolladores.

Dado que es una herramienta nueva para mi, explicare solo algunos pasos para su instalacion y configuracion.

Instalacion

sudo -E pip install gertty

Configuracion

curl https://git.openstack.org/cgit/openstack/gertty/plain/examples/openstack-gertty.yaml -o ~/.gertty.yaml
sed -i "s/CHANGEME/electrocucaracha/g" ~/.gertty.yaml
sed -i "s/sort-by//d" ~/.gertty.yaml
sed -i "s/revers//d" ~/.gertty.yaml
sudo chmod 0600 ~/.gertty.yaml

Cabe mencionar que la contraseña utilizada por el archivo de configuracion es la generada por gerrit. Una vez instalado y configurado es posible utilizarlo desde la terminal:

$ gertty

Nota: Inicialmente tuve problemas para mostrar la lista de proyectos de OpenStack, mi teoria es porque utilizaba una sesion de tmux para iniciar la aplicacion.