Utilizar Python 2.x y 3.x en la misma máquina

Actualmente me encuentro explorando el proyecto de Cross Community CI (XCI) de OPNFV que hace uso, entre otras cosas, del proyecto de OpenStack Bifrost para la creación de una imagen base y provisionamiento de la misma. En este momento el proyecto de Bifrost utiliza el cliente de Ansible en su versión estable 2.1. El equipo que utilizo tiene instalado ambas versiones de Python, pero varios errores son arrojados durante la ejecución del cliente de Ansible en su versión 2.1.6, para ser mas específicos, los errores son causados por el uso del método unicode que solo se encuentra disponible en versiones 2.x de python.

Como alternativa para solucionar este problema es posible forzar al Sistema Operativo a utilizar una versión de Python. La herramienta de pyenv permite instalar y trabajar con varias versiones de Python en la misma computadora y su instalación varia de acuerdo al Sistema Operativo utilizado.

En el caso de Sistemas Operativos con Linux su instalación puede realizarse con la siguiente instrucción en la linea de comandos:

$ curl -L https://raw.githubusercontent.com/yyuu/pyenv-installer/master/bin/pyenv-installer | bash

Y para los equipos con Mac OS, es posible a través del manejador de paquetes brew.

$ brew install pyenv

Dado que esta aplicación utiliza una carpeta para almacenar los binarios de las distintas versiones de Python y guardar los valores de usuario seleccionados es necesario definir la variable de ambiente PYENV_ROOT que especificará la carpeta a ser utilizada. Esta variable y la adición del binario en la variable PATH debe realizarse al momento de cargar la sesión de la consola.

Bash:

$ echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
$ echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
$ echo 'eval "$(pyenv init -)"' >> ~/.bashrc

Fish:

$ echo "pyenv init - | source" >> ~/.config/fish/config.fish 

Al iniciar la terminal los valores serán cargados y podremos hacer uso de los comandos, como lo es la instalación de versiones 2.7.14 y 3.5.4 de Python.

$ pyenv install 2.7.14
Downloading Python-2.7.14.tar.xz...
-> https://www.python.org/ftp/python/2.7.14/Python-2.7.14.tar.xz
Installing Python-2.7.14...
Installed Python-2.7.14 to /Users/vjmorale/.pyenv/versions/2.7.14
$ pyenv install 3.5.4
Downloading Python-3.5.4.tar.xz...
-> https://www.python.org/ftp/python/3.5.4/Python-3.5.4.tar.xz
Installing Python-3.5.4...
Installed Python-3.5.4 to /Users/vjmorale/.pyenv/versions/3.5.4

Por ultimo solo queda definir que versión quedara activa a lo largo del sistema. Esto se logra por medio del siguiente comando

$ pyenv global 3.5.4

Nota:
Aunque en mi caso no soluciono mi problema en particular, parece que es posible tener un resultado similar en sistemas Debian a traves del uso update-alternatives.

# update-alternatives --install /usr/bin/python python /usr/bin/python2.7 1
update-alternatives: using /usr/bin/python2.7 to provide /usr/bin/python (python) in auto mode
# update-alternatives --install /usr/bin/python python /usr/bin/python3.4 2
update-alternatives: using /usr/bin/python3.4 to provide /usr/bin/python (python) in auto mode
# update-alternatives --config python

Instalación de OPNFV a través de Compass4NFV

El proyecto de Open Platform for Network Function Virtualization (OPNFV) fue iniciado en Septiembre del 2014 como resultado del trabajo de European Telecommunications Standards Institute (ETSI) Industry Specification Group NFV (ETSI ISG NFV). Su comunidad selecciona proyectos de código abierto relevantes al área de redes y se dedica a integrarlos y probar su funcionalidad y desempeño para crear una plataforma de referencia de NFV y así acelerar la transformación de las empresas y proveedores de servicios de redes.

OPNFV utiliza OpenStack como Virtual Infrastructure Management (VIM), soporta múltiples controladores de SDN(OpenDaylight, ONOS y OpenContrail) y contiene tecnológicas de aceleración de paquetes como lo esData Plane Development Kit (DPDK). Para construir esta plataforma utiliza una metodología de integración continua y automatización de pruebas de los casos de uso de NFV claves para asegurar que se cumplan las necesidades de la industria NFV.

OPNFV libera cada seis meses una versión estable de su plataforma y tiene una nomenclatura basada en nombres de rios famosos (Arno – Jun’15, Brahmaputra – Mar’16, Colorado – Sept’16, Danube – Abr’17 y Euphrates). Además de contar con cuatro herramientas para su instalación como lo son:

  1. Compass
  2. Fuel
  3. TripleO
  4. Juju

Este articulo se centra en el análisis y uso de la primera herramienta compass4nfv.

En junio del 2017, durante la cumbre de OPNVF celebrada en Pekín, China se definieron varios puntos a mejorar para el release Euphrates. Una de las propuestas es agregar Kubernetes como componente de provisionamiento en la arquitectura.

Como consecuencia se han creado varios scripts que permiten un despliegue rápido y sencillo. Estos scripts ejecutan internamente dos scripts(build.sh y deploy.sh) para la construcción y despliegue de los distintos componentes, además de declarar variables de ambiente que definen el Sistema Operativo(OS_VERSION), la plataforma de cloud(KUBERNETES_VERSION o OPENSTACK_VERSION) y rutas de archivos de configuración. Estos archivos de configuración son dos:

  1. El archivo DHA utilizado para definir el escenario a desplegar, es decir las características a utilizar y los roles de cada servidor.
  2. El archivo de red que define los rangos de red para los servidores y

Al final el despliegue de un ambiente básico queda resumido en la ejecución del siguiente comando.

$ curl https://git.opnfv.org/compass4nfv/plain/quickstart.sh | bash

Ejecutar Ubuntu en Windows 10

En mi búsqueda por ejecutar git de una forma algo mas nativa encontré con esta solución que supongo utiliza un contenedor de Ubuntu. Esta característica solo se encuentra disponibles en versiones Windows 10 con build 4332+. Dado que se requieren cambios que aun se encuentran en fase beta, sugiero la creación de un punto de restauración.

El primer paso a realizar es activar el Modo de Desarrollador en Windows, para encontrar dicha opción de manera mas rapida podemos utilizar el cuadro de búsqueda.  Mas tarde, y  después de varias pantallas de confirmación reiniciaremos nuestra computadora.

Por ultimo no queda mas que abrir una consola de PowerShell en modo administrador y ejecutar el siguiente comando el cual habilitara la característica que estamos buscando.


PS C:\Windows\system32> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Una vez que la computadora haya reiniciado podemos utilizar bash como cualquier otra aplicación instalada en nuestro sistema, solo es necesario confirmar y esperar la descarga de la aplicación.

Laboratorio virtual de SDN

Es necesario poner el practica los conceptos aprendidos en la publicación anterior y realizar alguna prueba de concepto. Para ello he creado un proyecto en Vagrant el cual instala y configura un laboratorio de Software-Defined Network (SDN). A lo largo de esta publicación explicare los pasos del proceso de instalación para las distintas herramientas utilizadas y el como ejecutar una serie de ejercicios a modo de ejemplo.

El primer conjunto de instrucciones hace referencia a la instalación de Mininet. Esta aplicación nos permite emular una red virtual mediante la creación y conexión de hosts y switches. Existen tres maneras de obtener Mininet:

  1. Descargando una máquina virtual que previamente fue configurada desde su catalogo oficial.
  2. Mediante la instalación desde paquetes binarios (Ubuntu Trusty). Esto se logra mediante la ejecución del siguiente comando:
  3. # apt-get install -y mininet
    
    
  4. Por ultimo, mediante la instalación desde el código fuente. Este es el proceso utilizado en nuestro laboratorio, y se realiza con los siguientes comandos:
  5. 
    # apt-get install -y git
    # git clone https://github.com/mininet/mininet
    # bash mininet/util/install.sh
    
    

Una vez que tenemos instalado Mininet, el cual necesitaremos para la emulación de nuestra infraestructura, pasaremos a la instalación de un controlador. En este caso utilizaremos OpenDayLight (ODL), el cual ofrece una plataforma funcional de SDN. Distintas versiones de OpenDayLight son ofrecidas desde su repositorio oficial, por lo tanto solo es necesario realizar dos acciones:

  1. Instalar la maquina virtual de java
    
    # apt-get update -y
    # apt-get install -y software-properties-common
    # add-apt-repository -y ppa:openjdk-r/ppa
    # apt-get update -y
    # apt-get install -y openjdk-8-jdk
    
    
  2. Descargar, descomprimir e inicar la version de OpenDayLight deseada
    
    $ odl_release=0.6.0-Carbon
    $ odl_distribution=distribution-karaf
    $ wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/$odl_distribution/$odl_release/$odl_distribution-$odl_release.tar.gz
    $ tar xf $odl_distribution-$odl_release.tar.gz
    $ cd $odl_distribution-$odl_release
    $ export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/jre
    $ ./bin/start
    
    

Una vez iniciado el servicio de karaf, necesitaremos agregar mas funcionalidades que nos ayudaran a visualizar y conectar nuestro infraestructura virtual. Esto se logra a traves de la instalación de features desde el servicio.


./bin/client feature:install odl-dlux-core odl-dluxapps-topology odl-restconf odl-l2switch-switch

Dado que Mininet fue escrito en python es posible crear una aplicación que nos genere una infraestructura virtual dinámicamente, el siguiente ejemplo muestra como utilizar clases y modulos para generar una infraestructura virtual con Mininet.

from mininet.topo import Topo

class MyTopo( Topo ):
    "Simple topology example."

    def __init__( self ):
        "Create custom topo."

        # Initialize topology
        Topo.__init__( self )

        # Add hosts and switches
        leftHost = self.addHost( 'h1' )
        rightHost = self.addHost( 'h2' )
        leftSwitch = self.addSwitch( 's3' )
        rightSwitch = self.addSwitch( 's4' )

        # Add links
        self.addLink( leftHost, leftSwitch )
        self.addLink( leftSwitch, rightSwitch )
        self.addLink( rightSwitch, rightHost )


topos = { 'mytopo': ( lambda: MyTopo() ) }"

Por ultimo es necesario especificar la URL de la API del Controlador(OpenDayLight), en nuestro ejemplo este servicio se encuentra instalado en la misma máquina por lo que se utilizara la dirección del localhost. Los siguientes dos comandos nos permitirán capturar información necesaria para mostrar los componentes, el primero es para generar y conectar la infraestructura virtual con el controlador y el segundo solo que generará trafico.

# mn --custom ~/topologies/example01.py --topo mytopo --controller=remote,ip=127.0.0.1,port=6633
*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s3 s4
*** Adding links:
(h1, s3) (s3, s4) (s4, h2)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 2 switches
s3 s4 ...
*** Starting CLI:
mininet> pingall
*** Ping: testing ping reachability
h1 -> h2
h2 -> h1
*** Results: 0% dropped (2/2 received)

Uno de los features instalados (DLUX para ser mas precisos) en el Controlador nos permite acceder mediante un portal a ODL. Escribiendo la URL http://10.0.0.2:8181/index.html en cualquier navegador de internet y especificando las credenciales del usuario “admin” con la contraseña “admin“.

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.