Graduado en Ingeniería Informática Universidad Politécnica de Madrid Escuela Técnica Superior de Ingenieros Informáticos TRABAJO DE FIN DE GRADO Dashboard configurable para la gestión y administración de una instancia de OpenStack Autor: Braulio Grana Gutiérrez Director: Miguel Jiménez Gañán MADRID, JUNIO 2015
103
Embed
Dashboard configurable para la gestión y …oa.upm.es/38353/7/TFG_BRAULIO_GRANA_GUTIERREZ.pdfOpenStack is a free and open source platform used as Infrastructure as a Service (IaaS)
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Graduado en Ingeniería Informática
Universidad Politécnica de Madrid
Escuela Técnica Superior de Ingenieros
Informáticos
TRABAJO DE FIN DE GRADO
Dashboard configurable para la gestióny administración de una instancia de
En este documento está descrito detalladamente el trabajo realizado para com-
pletar todos objetivos marcados para este Trabajo de Fin de Grado, que tiene como
meta final el desarrollo de un dashboard configurable de gestión y administración
para instancias de OpenStack.
OpenStack es una plataforma libre y de código abierto utilizada como solución
de Infraestructura como Servicio (Infrastructure as a Service, IaaS) en clouds tanto
públicos, que ofrecen sus servicios cobrando el tiempo de uso o los recursos utili-
zados, como privados para su utilización exclusiva en el entorno de una empresa. El
proyecto OpenStack se inició como una colaboración entre la NASA y RackSpace,
y a día de hoy es mantenido por las empresas más potentes del sector tecnológico a
través de la Fundación OpenStack.
La plataforma OpenStack permite el acceso a sus servicios a través de una In-
terfaz de Linea de Comandos (Command Line Interface, CLI), una API RESTful y
una interfaz web en forma de dashboard. Esta última es ofrecida a través del servi-
cio Horizon. Este servicio provee de una interfaz gráfica para acceder, gestionar y
automatizar servicios basados en cloud. El dashboard de Horizon presente algunos
problemas como que:
solo admite opciones de configuración mediante código Python, lo que hace
que el usuario no tenga ninguna capacidad de configuración y que el adminis-
trador esté obligado a interactuar directamente con el código.
no tiene soporte para múltiples regiones que permitan que un usuario pueda
distribuir sus recursos por distintos centros de datos en diversas localizaciones
como más le convenga.
El presente Trabajo de Fin de Grado, que es la fase inicial del proyecto FI-Dash,
pretende solucionar estos problemas mediante el desarrollo de un catálogo de widget
de la plataforma WireCloud que permitirán al usuario tener todas las funcionalidades
ofrecidas por Horizon a la vez que le ofrecen capacidades de configuración y añaden
funcionalidades no presentes en Horizon como el soporte de múltiples regiones.
Como paso previo al desarrollo del catálogo de widgets se ha llevado a cabo
un estudio de las tecnologías y servicios ofrecidos por OpenStack, así como de las
herramientas que pudieran ser necesarias para la realización del trabajo.
El proceso de desarrollo ha sido dividido en distintas fases de acuerdo con los
distintos componentes que forman parte del dashboard cada uno con una funcion de
gestion sobre un tipo de recurso distinto. Las otras fases del desarrollo han sido la
integración completa del dashboard en la plataforma WireCloud y el diseño de una
interfaz gráfica usable y atractiva.
vii
Abstract
Throughout this document it is described the work performed in order to achieveall of the objectives set for this Final Project, which has as its main goal the de-velopment of a configurable dashboard for managing and administrating OpenStackinstances.
OpenStack is a free and open source platform used as Infrastructure as a Service(IaaS) for both public clouds, which offer their services through payments on time orresources used, and private clouds for use only in the company’s environment. TheOpenStack project started as a collaboration between NASA and Rackspace, andnowadays is maintained by the most powerful companies in the technology sectorthrough the OpenStack Foundation.
The OpenStack project provides access to its services through a Command LineInterface (CLI), a RESTful API and a web interface as dashboard. The latter is of-fered through a service called Horizon. This service provides a graphical interface toaccess, manage and automate cloud-based services. Horizon’s dashboard presentssome problems such as:
Only supports configuration options using Python code, which grants the userno configuration capabilities and forces the administrator to interact directly.No support for multiple regions that allow a user to allocate his resources bydifferent data centers in different locations at his convenience.
This Final Project, which is the initial stage of the FI-Dash project, aims tosolve these problems by developing a catalog of widgets for the WireCloud platformthat will allow the user to have all the features offered by Horizon while offeringconfiguration capabilities and additional features not present in Horizon such assupport for multiple regions.
As a prelude to the development of the widget catalog, a study of technologiesand services offered by OpenStack as well as tools that may be necessary to carryout the work has been conducted.
The development process has been split in phases matching the different compo-nents that are part of the dashboard, having each one of them a function of manage-ment of one kind of resource. The other development phases have been the achievingof full integration with WireCloud and the design of a graphical interface that is bothusable and atractive.
viii
Capítulo 1
INTRODUCCIÓN Y OBJETIVOS
La computación en la nube se ha convertido en los últimos años en una herramienta
fundamental en los sistemas de información. La escalabilidad, elasticidad y facilidad a la
hora de ofrecer servicios a nivel mundial han sido factores clave en el éxito de este tipo de
tecnologías, tanto en Clouds públicos, como Amazon Web Services (AWS) o Rackspace,
como en Clouds privados para uso interno de la empresa que los desea explotar.
OpenStack es un servicio de computación en la nube gratuito y de código libre, que
los usuarios pueden utilizar como una solución de infraestructura como servicio (Infras-tructure as a Service, IaaS), tanto para Clouds privados de uso interno en una empresa,
como para Clouds públicos que oferten recursos virtualizados a cualquier cliente.
El proyecto OpenStack consiste en una serie de servicios interrelacionados que ofre-
cen gestión y administración de dichos recursos virtualizados de almacenamiento, proce-
samiento y comunicación en red, que los usuarios pueden manejar a través de una interfaz
web (Horizon), la línea de comandos o una API [10] Rest [11].
El servicio Horizon, que es parte del proyecto OpenStack, ofrece una interfaz gráfica
de gestión a administradores y usuarios para acceder, automatizar y configurar recursos
de OpenStack. Este dashboard ofrecido por OpenStack tiene algunas desventajas como
no permitir la realización de cambios de configuración sin acceder al código python de
la aplicación o no soportar la gestión de múltiples regiones con una misma instalación de
OpenStack.
El presente trabajo de fin de grado, que es la fase inicial del proyecto FI-Dash, pretende
ofrecer un dashboard de gestión y administración para OpenStack en forma de aplicación
composicional, enfatizando la capacidad y facilidad de configuración por parte del usua-
rio.
1
CAPÍTULO 1. INTRODUCCIÓN Y OBJETIVOS
1.1 Motivaciones
La interfaz web ofrecida por el proyecto OpenStack (Horizon), ofrece una interfaz de
configuración para un subconjunto de los servicios y operaciones disponibles en OpenStack,
aunque permite añadir cualquier servicio nuevo sin afectar a los ya existentes.
Un problema de Horizon es que, aunque el dashboard ofrecido admite opciones de
configuración, estas sólo están disponibles mediante la modificación de código Python,
esto hace que el usuario no tenga ninguna capacidad de configuración del dashboard y que
el administrador se vea obligado a interactuar directamente con el código para realizar
cualquier modificación de configuración.
Otro problema importante a destacar es que en FIWARE las regiones están imple-
mentadas a través de múltiples instalaciones federadas y Horizon no tiene soporte para
este tipo de distribución. Tener múltiples instalaciones de OpenStack federadas a modo
de regiones permite localizar los servicios en distintos centros de datos para ofrecer una
solución total a empresas con una localización geográfica dispersa.
Para solucionar estos problemas de Horizon, se plantea crear una interfaz basada en
widgets de la plataforma WireCloud que podrán componerse para formar un dashboardde gestión que integre las funcionalidades ofrecidas por cada uno de los widgets. Esta
estructura permitirá al usuario añadir nuevas funcionalidades o modificar las existentes,
sin afectar al resto, y aumentará considerablemente la capacidad de configuración del
dashboard.
Además, una ventaja inherente de las aplicaciones composicionales como es WireCloud
es integrar servicios de múltiples fuentes en un mismo mashup de forma homogénea. Esto
puede ser útil si se quiere añadir al dashboard cualquier alguna funcionalidad que requiera
de un servicio externo.
Los widgets utilizarán el sistema editor de conexiones de WireCloud para conectar sus
entradas y salidas con las de otros widgets y así poder enviar y recibir datos a través de
las mismas. Se maximizarán las entradas y salidas de los widgets para permitir todas las
composiciones posibles entre ellos. Para que el usuario pueda conectar todos los widgetsque desee de manera sencilla e intuitiva, se utilizará un sistema de friendcodes que rela-
cionará cada salida de un widget con las entradas de los otros widgets a las que se pueda
conectar, es decir, aquellas que tengan el mismo friendcode.
Cabe destacar que, aunque la utilización de WireCloud permitiría integrar múltiples
APIs y servicios de terceros, el presente Trabajo de Fin de Grado se centra en aquellos
2
CAPÍTULO 1. INTRODUCCIÓN Y OBJETIVOS
servicios ofrecidos por OpenStack a través de APIs REST. La integración de los datos de
monitorización de los servidores y otros servicios del proyecto FIWARE queda fuera del
ámbito de este Trabajo de Fin de Grado.
1.2 Objetivos
De acuerdo con lo expuesto en apartados anteriores los principales objetivos de este
Trabajo de Fin de Grado serían:
Analizar las diferences APIs REST que ofrece cada uno de los servicios de OpenStack
con el fin de conocer el alcance potencial del proyecto, centrándose en aquellas
funcionalidades no ofrecidas por el dashboard Horizon y que, por tanto, serían una
mejora de las interfaces ya existentes.
Definir todos aquellos tipos de información que puede manejar OpenStack de cara
a utilizarlos como puntos de entrada o salida (endpoints) de cada uno de los widgetsque facilitarán la composición de dashboards personalizados.
Integrar la autenticación y autorización de las operaciones sobre los distintos servi-
cios ofrecidos por OpenStack en una librería integrada en la plataforma WireCloud.
De esta manera se conseguirá que la autenticación sea transparente para el usuario
final, quien sólo tendrá que autenticarse en la plataforma WireCloud para acceder,
gestionar y administrar sus recursos virtualizados en la nube. Al mismo tiempo
esto restará carga de trabajo a los widgets, ya que no tendrán que autenticarse in-
dividualmente sino que se aprovecharán del token de autenticación ofrecido por la
plataforma.
Desarrollo de un catálogo de widgets que permita gestionar, de forma básica, los
servicios ofrecidos por OpenStack en materia de almacenamiento (volúmenes) y
computación (imágenes e instancias), además de funcionalidades añadidas para la
gestión de múltiples regiones.
3
CAPÍTULO 1. INTRODUCCIÓN Y OBJETIVOS
4
Capítulo 2
ESTADO DEL ARTE
De manera previa a la realización del trabajo, se ha llevado a cabo un estudio sobre las
tecnologías ya existentes en el ámbito a tratar y las opciones que estas nos ofrecen. A lo
largo de este capítulo se ofrecen los resultados de dicho estudio.
En primer lugar, se ofrece un breve resumen del resultado del análisis de la documen-
tación y referencia de las APIs de los servicios de OpenStack para conocer el alcance y
funcionalidad que ofrece el proyecto.
A continuación, se incluyen las tecnologías de desarrollo web en lado cliente más usa-
das actualmente, así como herramientas y conceptos específicas para el problema tratado
en este Trabajo de Fin de Grado.
Dado que el trabajo utiliza la plataforma WireCloud [4] y el Cloud [5] pertenecientes
al proyecto FIWARE [2] como base sobre la que realizar las aplicaciones se han incluido
apartados sobre dichas plataformas a fin de ayudar a comprender su utilidad para la tarea
planteada. También se incluyen descripciones de los distintos tipos de aplicaciones que se
pueden llevar a cabo en WireCloud.
Finalmente, se muestran las herramientas de control de versiones, testing e integración
continua que se van a utilizar para controlar la evolución y funcionalidad del dashboard.
2.1 Tecnologías de computación en la nube
La computación en la nube permite ofrecer cualquier tipo de aplicación como un servi-
cio a través de internet. Este paradigma comenzó en proveedores de servicios en internet
5
CAPÍTULO 2. ESTADO DEL ARTE
como Google, Amazon o Microsoft, que contruyeron su propia infraestructura, pero hoy
en día cualquier empresa puede ofrecer este tipo de servicio pagando a un cloud público
por el uso de la infraestructura.
Tradicionalmente, se han definido tres capas en la computación en la nube:
Software como Servicio (Software as a Service, SaaS)Una aplicación ofrecida como servicio a varios clientes de manera simultánea. Una
aplicación de este tipo suele ser accesible a través del navegador web y evita al
cliente tener que instalar nuevo software en su equipo. Algunos servicios de Google
como Drive o Gmail son buenos ejemplos de SaaS.
Plataforma como Servicio (Plataform as a Service, PaaS)Entorno completo de desarrollo preparado para ser utilizado como un servicio. Vie-
nen con una serie de tecnologías integradas que permiten el desarrollo de tipos
concretos de aplicación o de otras más generales. Google App Engine o Microsoft
Azure son algunos ejemplos de PaaS.
Infraestructura como Servicio (Infrastructure as a Service, IaaS)Esta capa permite ofrecer capacidad de almacenamiento, de cómputo y de red, como
servicios a través de internet. Se suelen utilizar tecnologías de virtualización para
manejar los recursos de cada usuario.
Dentro de las IaaS encontramos soluciones de cloud pública como Amazon Web
Services, Rackspace y Microsoft Azure entre otras y también soluciones de cloudprivado para su instalación dentro de la empresa permitiendo a esta tener el control
total de sus recursos. Algunos ejemplos de soluciones privadas son CloudStack,
OpenNebula y OpenStack.
2.2 OpenStack
OpenStack [1] es un proyecto de computación en la nube libre y de código abierto que
tiene como finalidad ofrecer un conjunto de servicios para proporcionar IaaS. El proyecto
es gestionado por la Fundación OpenStack y respaldado por algunas de las empresas más
grandes del sector como Google, IBM, Yahoo!, HP, Rackspace o AMD.
OpenStack es desarrollado por una comunidad muy activa y tiene un ciclo de lanza-
miento de versiones semestral.
6
CAPÍTULO 2. ESTADO DEL ARTE
En Kilo, la versión más reciente de OpenStack (abril 2015), los principales servicios
ofrecidos son los siguientes:
Nova (Computación)Este módulo es el núcleo de OpenStack, un controlador de estructura de compu-
tación. Se usa para crear máquinas virtuales (instancias) y manejar tareas compu-
tacionales. La arquitectura de Nova esta diseñada para escalar horizontalmente en
hardware estándar y proporcionar integración con sistemas antiguos y tecnologías
de terceros.
Cinder (Block Storage)Es el módulo de almacenamiento de bloques, análogo a la tradicional idea de ac-
ceder localizaciones específicas en un disco duro. Cinder maneja lo que se llaman
volúmenes de datos persistentes que se pueden usar contra instancias de Nova. El
almacenamiento de bloques es apropiado para escenarios donde un alto rendimiento
es importante.
Glance (Imágenes)Proporciona servicios de imágenes. En este caso imagen se refiere a copias virtuales
de discos. Glance permite usar dichas imágenes como plantilla a la hora de desple-
gar una nueva instancia en Nova. Por ejemplo, se podría utilizar una imágen del
sistema operativo Ubuntu para crear una máquina virtual (instancia de Nova) con el
mencionado sistema instalado.
Swift (Object Storage)Ofrece servicio de almacenamiento redundante y escalable. La idea detrás de Swift
es referirse a los objetos y archivos mediante un identificador en lugar de hacerlo
como se ha hecho tradicionalmente mediante su localización en el disco duro. Esto
hace que la escalabilidad sea fácil ya que, al poder almacenar los archivos y objetos
en múltiples discos dejando que el servicio se encargue de su identificación, locali-
zación y redundancia, se permite que el desarrollador no tenga que preocuparse por
problemas de espacio. Además, las agrupaciones de datos en Swift pueden escalar
Neutron (Networking)Es el módulo que gestiona las redes y direcciones IP de las máquinas virtuales.
Asegura que la red no presente problemas y que las instancias puedan comunicarse
entre sí rápida y eficientemente.
Keystone (Identificación)
7
CAPÍTULO 2. ESTADO DEL ARTE
Proporciona servicio de autenticación y autorización usado por todos los demás ser-
vicios de OpenStack para validar las operaciones de un usuario. Es, esencialmente
una lista centralizada de todos los usuarios de una instalación de OpenStack ma-
peada contra todos los servicios. A través del módulo keystone, el usuario adquiere
permisos para hacer uso de cada servicio de OpenStack que los administradores le
permitan usar.
Ceilometer (Telemetría)Proporciona servicios de facturación. Mantiene la cuenta del uso que ha hecho cada
usuario de cada uno de los servicios de OpenStack a través de contadores. Se utiliza
para establecer la facturación del cliente en un período dado.
Heat (Orquestación)Permite a los desarrolladores almacenar los requerimientos de recursos necesarios
para una aplicación dada en la nube. De esta manera, ayuda a definir la infraestruc-
tura necesaria para ejecutar un servicio en la nube.
Trove (Base de datos)Permite a los desarrolladores utilizar de manera rápida y sencilla las capacidades de
bases de datos relacionales y no-relacionales sin la carga extra de complejas tareas
de administración.
Horizon (Dashboard)Horizon es la única interfaz gráfica disponible para OpenStack actualmente. Desde
este dashboard los usuarios pueden acceder a la mayoría de los servicios ofrecidos
por OpenStack, pero no a todos. Permite administrar los recursos virtualizados de
un usuario (o de todo el Cloud en caso de ser administrador). El principal problema
de esta interfaz es que no es modificable ni personalizable a nivel de funcionalidad
sin acceder al código fuente. También tiene la desventaja de que está pensada para
gestionar una única instalación de OpenStack y no es compatible con la gestión de
múltiples regiones en la manera que están implementadas en FIWARE a través de
múltiples instalaciones federadas de OpenStack.
Sahara (Procesamiento de datos)Sahara tiene como objetivo proporcionar al usuario maneras simples de desplegar
un cluster Hadoop en OpenStack especificando parámetros como la versión de Ha-
doop, la topología detalles de los nodos hardware y algunos más. De esta manera
un usuario puede desplegar en unos minutos un cluster MapReduce.
Ironic (Máquinas físicas)
8
CAPÍTULO 2. ESTADO DEL ARTE
Este servicio proporciona máquinas físicas en lugar de virtuales permitiendo el uso
de drivers específicos de fabricantes. El uso de máquinas físicas en lugar de virtua-
les puede ser útil en casos en que sea necesario un cluster de alto rendimiento, o el
acceso a hardware que no puede ser virtualizado entre otros.
Zaqar (Mensajería en la nube)Es un servicio de mensajería cloud para desarrolladores que permite enviar, a tra-
vés de una API RESTful, múltiples mensajes entre distintos componentes de una
aplicación móvil o SaaS. Zaqar es un motor de mensajería eficiente diseñado con la
seguridad y la escalabilidad en mente.
Barbican (Almacenamiento seguro)Barbican es una API REST diseñada para almacenar, gestionar y aprovisionar de
manera segura distintos tipos de claves, ya sean simétricas, asimétricas o claves
guardadas como bloques binarios.
Además, en Kilo vienen incluidos otros servicios que aún están en fases tempranas de
desarrollo y aún no son ampliamente usados como Designate (DNSaaS), Manila (sistema
de ficheros compartido) y otros.
Figura 2.1: Diagrama de la arquitectura OpenStack
9
CAPÍTULO 2. ESTADO DEL ARTE
2.3 Tipos de recurso en OpenStack
En una instalación de OpenStack se pueden gestionar varios tipos de recursos que
pueden ser imágenes, instancias, flavors, redes, volúmenes, IPs, grupos de seguridad y
otros. En el contexto de este Trabajo de Fin de Grado se van a gestionar en mayor medida
los recursos de imágenes, instancias y volúmenes.
2.3.1 Imágenes
Una imagen es un tipo de archivo que contiene la estructura de un disco o una unidad de
almacenamiento al completo. Una imagen de disco normalmente se produce haciendo una
copia completa sector a sector del medio origen, replicando así la estructura y contenidos
del dispositivo. El medio origen puede ser un CD, un DVD, un USB u otros medios
dependiendo del formato de la imagen.
Las imágenes de disco suelen utilizarse con propósitos de virtualización. La virtuali-
zación de una imagen es interpretada por un monitor de máquina virtual como un disco.
Otro uso muy importante de las imágenes es la creación de imágenes de sistema, que ofre-
cen el estado de un sistema en un archivo no volátil incluyendo información de arranque.
Esto permite la instalación de sistemas operativos a través de la información almacenada
en este tipo de archivos.
En el contexto de la computación en la nube, las imágenes pueden ser vistas como
plantillas de sistemas de fichero de máquinas virtuales. Un cloud de computación de
OpenStack no es demasiado útil sin imágenes a partir de las que crear máquinas vir-
tuales. Una imagen de máquina virtual es un tipo de imagen de disco que contiene un
disco virtual con un sistema operativo arrancable instalado en él.
Formatos
Las imágenes de máquinas virtuales suelen venir en uno de los siguientes tipos de
archivo:
RawEs el formato más simple, equivalente a un archivo de bloques de un disco, creado
a partir de la copia directa del disco por ejemplo con un comando dd. Este formato
es soportado por los hypervisors KVM y Xen.
10
CAPÍTULO 2. ESTADO DEL ARTE
qcow2QEMU Copy-On-Write version 2. Este formato se usa normalmente con el hyper-visor KVM y tiene algunas características que no posee el formato Raw como el
uso de la representación sparse, que genera ficheros de imagen más pequeños o el
soporte para snapshots.
AMI/AKI/ARIEs el formato de imágenes que se usaba inicialmente en el EC2 de Amazon. Con-
siste en una imagen compuesta por tres archivos: el AMI (Amazon Machine Image),
que es una imagen de máquina virtual en formato raw, el AKI (Amazon Kernel Ima-ge), que es una imagen del kernel que el hypervisor cargara para arrancar la imagen
y el ARI (Amazon Ramdisk Image), que sería el equivalente al archivo initrd en un
sistema Linux y es opcional si el kernel ya tiene los módulos para acceder al sistema
de ficheros root.
ISOEste formato consiste en un archivo con un sistema de ficheros con el formato ISO
9660 de solo lectura.
ODF(Open Virtualization Format). Es una formato de paquetización para máquinas vir-
tuales definido por el DMTF (Distributed Management Task Force). Un fichero
OVF puede contener una o más imágenes y un fichero de extensión .ovf con mata-
datos en formato XML. OpenStack aún no soporta el formato OVF pero basta con
extraer la imagen del interior del paquete y subirla a OpenStack.
También hay otros formatos específicos de determinados software como por ejemplo
JQuery [19] es una librería JavaScript que permite simplificar la manera de interactuar
con los documentos HTML, manipular el DOM, manejar eventos, desarrollar animaciones
y agregar interacción con AJAX.
20
CAPÍTULO 2. ESTADO DEL ARTE
JQuery es la librería de JavaScript más utilizada del mundo y su gran éxito se debe
sobre todo a las facilidades que aporta a la hora de seleccionar elementos del DOM y a
sus numerosas extensiones que la convierten en una librería muy fácil de usar por usuarios
novatos y que ahorra tiempo a desarrolladores más expertos. Gracias a esta herramienta
se puede agilizar y simplificar el desarrollo de aplicaciones web a la vez que se mantiene
la calidad y legibilidad del código.
Se puede acceder a toda su funcionalidad a través de la función $(), que es un alias
para JQuery().
2.5 FIWARE
FIWARE [2] es un proyecto de ámbito europeo en el que participan varias de las gran-
des empresas del sector tecnológico como IBM y Telefónica. Tiene por objetivo el desa-
rrollo de nuevas aplicaciones aprovechando las oportunidades brindadas por las últimas
tecnologías digitales. El proyecto es de código libre y todas sus aplicaciones están dispo-
nibles públicamente de manera gratuita.
FIWARE se basa en varios pilares como son:
FIWARE Ops, que es un conjunto de herramientas destinadas a facilitar el desarro-
llo y despligue de aplicaciones creadas dentro de FIWARE.
FIWARE Accelerate, que tiene como objetivo la promoción de las aplicaciones de
FIWARE entre desarrolladores y empresas.
FIWARE Mundus, que pretende expandir el alcance del proyecto FIWARE mas allá
de las fronteras europeas.
FIWARE Lab, un entorno de desarrollo no comercial destinado a la creación de
aplicaciones innovadoras utilizando datos públicos de ciudades y otras organiza-
ciones.
Precisamente en FIWARE Lab están incluidas dos plataformas que serán utilizadas en
este proyecto como son WireCloud y el portal Cloud.
21
CAPÍTULO 2. ESTADO DEL ARTE
2.5.1 Plataforma WireCloud
WireCloud [4] es una plataforma web escrita en Django que ofrece a cualquier usua-
rio la posibilidad de crear mashups a partir de wdigets componibles de manera rápida y
sencilla. Esta plataforma es desarrollada y mantenida en la Escuela Técnica Superior de
Ingenieros Informáticos de la Universidad Politécnica de Madrid, en el laboratorio CoN-
WeT (Computer Networks and Web Technologies) [3].
La plataforma WireCloud forma parte del proyecto europeo FIWARE. Dentro de este
proyecto, WireCloud es uno de los llamados Generic Enablers denominado Application
Mashup. A consecuencia de esto, WireCloud implementa todas las APIs definidas en el
Generic Enabler cuya documentación se encuentra en la página oficial de FIWARE.
Esta plataforma permite los desarrolladores crear aplicaciones composicionales por
medio de widgets, operadores y mashups. Debido al caracter modular de las aplicaciones
creadas con estos componentes se facilita al desarrollador poder reutilizarlos en otras
aplicaciones así como compartirlos con los demás.
Al usuario no desarrollador WireCloud le permite modificar la interfaz añadiendo o
quitando widgets y operadores y cambiar sus conexiones o crear un nuevo espacio de
trabajo desde cero añadiendo un mashup. Además, los usuario pueden compartir sus mas-hups con otros.
El editor del mapa de conexiones entre componentes es lo que hace que WireCloud
sea la plataforma elegida para desarrollar el dashboard de este trabajo, ya que permite la
edición por parte del usuario de manera rápida, sencilla y amigable de las funcionalidades
presentes en el dashboard en un momento dado.
2.5.2 Cloud
El portal Cloud [5], incluido como Generic Enabler dentro del proyecto FIWARE pro-
vee de un servicio de computación en la nube haciendo uso de OpenStack. Este portal está
gestionado por Telefónica y tiene un uso experimental y no de producción lo que hace que
su funcionalidad no siempre sea la óptima.
Será este Cloud el que se utilice en este Trabajo de Fin de Grado para realizar pruebas
del dashboard para realizar pruebas contra una instalación real de OpenStack.
22
CAPÍTULO 2. ESTADO DEL ARTE
Figura 2.6: Composición de un mashup en el editor de conexiones de WireCloud
2.6 Tipos de componentes web en WireCloud
Con el objetivo de tener un mejor entendimiento de las distintas partes que compondrán
el dashboard, en este apartado se describen los distintos tipos de aplicaciones web que se
pueden crear y utilizar en la plataforma WireCloud.
2.6.1 Widget
Un widget [16] es una pequeña aplicación o programa. El término puede aplicarse a
varios tipos de programas en plataformas muy distintas como aplicaciones de escritorio
o para móviles, pero para el propósito de este Trabajo de Fin de Grado solo interesan los
widgets web.
Un widget web es una aplicación relativamente pequeña en JavaScript que representa
una funcionalidad o contenido muy concreto que puede ser añadido a una web de manera
muy sencilla.
En el caso de la plataforma WireCloud los widget constan solamente de una interfaz
gráfica que se apoya en uno o más servicios de backend. Generalmente los servicios en
los que se apoya el widget son pocos ya que tiene una funcionalidad definida. Y es esta
funcionalidad definida lo que hace que sean tan reutilizables, sobre todo en el contexto
de WireCloud en el que se conectan a través del sistema de conexiones, que los hace más
versátiles y facilita la creación de widgets muy específicos.
23
CAPÍTULO 2. ESTADO DEL ARTE
Figura 2.7: Ejemplos de widget
Los widgets tienen, además, opciones de configuración que puede definir el desarro-
llador y posteriormente modificar el usuario y que influyen en el aspecto de la interfaz.
Además, cada widget está definido se incrusta en la interfaz de la plataforma en su propio
iFrame por lo que se pueden tener varias instancias del mismo en el mismo espacio de
trabajo.
Como ya se ha mencionado, un widget puede conectarse con cualquier servicio en
internet y pedirle datos que luego puede ofrecerle al usuario. En el caso del presente
Trabajo de Fin de Grado, esos datos serán recursos virtuales de OpenStack.
2.6.2 Operador
En la plataforma WireCloud un operador es una aplicación que, al igual que los widgets,
puede conectarse a otras a través de sus entradas y salidas, con la diferencia de que carece
de interfaz gráfica.
Están pensados como aplicaciones proveedoras de datos y lógica a varios widgets y
que, por tanto, no necesitan una interfaz gráfica. Sus usos en el desarrollo son dos princi-
palmente:
Transformación de datos, actuando como filtros, realizando operaciones, uniendo
múltiples datos, etc.
Acceso a servicios complejos de backend, lo que permite que un usuario defina la
24
CAPÍTULO 2. ESTADO DEL ARTE
fuente de los datos de un widget de forma más flexible.
2.6.3 Mashup
Un mashup [17] es una aplicación web creada a partir de la reutilización de otras
aplicaciones más simples (como widgets), para conseguir una funcionalidad mayor. El
término mashup implica integración fácil y rápida, normalmente usando varias APIs y
fuentes de datos abiertas.
La arquitectura de un mashup consta de tres partes:
El proveedor de datos Normalmente disponible a través de una API.
El sitio mashup aplicación web que ofrece un servicio utilizando información que no es
propia.
El navegador web cliente es la interfaz de usuario del mashup.
Figura 2.8: Arquitectura mashup
En WireCloud, un mashup es una composición predefinidad e widgets y operadores.
En ellos hay unas conexiones definidas y unas propiedades establecidas por lo que se
convierten en aplicaciones listas para utilizar.
25
CAPÍTULO 2. ESTADO DEL ARTE
2.7 Git
Git [13] es un software de control de versiones desarrollado por Linus Torvalds y
Junio Hamano. Es una gran herramienta para el desarrollo de proyectos llevados a cabo
por varias personas y para mantener control de quién ha modificado qué fichero en qué
momento.
Figura 2.9: Ejemplo de flujo de desarrollo en Git
Git le da a cada programador una copia local del historial de desarrollo entero y los
cambios se propagan entre los repositorios locales. También tiene un historial de versiones
o commits que permiten mantener un control sobre como ha evolucionado el código de un
proyecto y volver a versiones anteriores de manera rápida con un comando. Además, Git
permite mantener distintas líneas de desarrollo a la vez a través de las ramas, que se crean
a partir de una bifurcación de una rama previa (dos commits distintos tienen el mismo
commit asociado como anterior).
Aunque cada desarrollador puede usar Git de la manera que crea más conveniente, es
buena práctica que cada proyecto tenga las siguientes ramas:
MasterEs la rama que lleva el control de la versión más estable del software.
DevelopmentRama sacada de master que contiene la última versión del código con todos los
cambios que aún no han sido integrados en una versión estable. Todas las nuevas
funcionalidades se deberian integrar en esta rama.
Features
26
CAPÍTULO 2. ESTADO DEL ARTE
Cada nueva funcionalidad se debería desarrollar en su propia rama para luego hacer
un merge (unir dos ramas) contra development.
HotfixEstas ramas corresponden a bugs que surgen en producción por lo que se deben
arreglar y publicar urgentemente. Se debe hacer merge de esta rama contra Master,
y luego de Master con Development para que no se quede desfasada.
Git puede ser usado tanto a través de la consola, como a través de una interfaz gráfica.
Existen, además, diferentes servicios para almacenar repositorios. Entre los más conoci-
dos están GitHub, BitBucket y GitLab.
Este tipo de servicios de almacenamiento de repositorios suelen ofrecer las mismas
funcionalidades, por ejemplo, creación de repositorios, creación de forks de otros proyec-
tos (crear un repositorio nuevo a partir del de otro usuario y continuar tu propia línea de
desarrollo) o la creación de issues, que permiten tanto a los desarrolladores como a los
demás usuarios crear tickets indicando un bug o una mejora posible en el código.
2.8 Pruebas unitarias
Una prueba unitaria [21] es una forma de comprobar el funcionamiento de un módulo
o función no trivial. De esta manera, se pretende asegurar el correcto funcionamiento de
cada módulo por separado. Las pruebas unitarias deben ser independientes las unas de las
otras.
Un programa que dispone de un buen conjunto de pruebas unitarias automatizadas
tiene la posibilidad de encontrar sus problemas en etapas tempranas de su ciclo de desa-
rrollo. Además, un buen conjunto de pruebas facilita los cambios y las refactorizaciones
de código ya que permite asegurar el correcto funcionamiento del programa después de
cada cambio. Otra ventaja es que facilita la integración de las distintas partes de un siste-
ma para la realización de pruebas a mayor escala, ya que se asegura que cada parte ya ha
sido probada por separado.
2.8.1 Jasmine
Jasmine [22] es una librería de JavaScript para la realización de pruebas unitarias que
es fácil de leer y permite la ejecución de las pruebas en cualquier plataforma que pueda
27
CAPÍTULO 2. ESTADO DEL ARTE
ejecutar código JavaScript. No depende de ninguna otra librería de JavaScript ni requiere
un DOM para funcionar.
Jasmine permite definir suites de test a traves de la función describe() y dentro de
estas, establecer los distintos casos de prueba usando la función it(). Como la mayoría de
las librerías de pruebas, Jasmine ofrece la posibilidad de ejecutar código antes y despues
de cada prueba usando las funciones beforeEach() y afterEach().
Jasmine cuenta con múltiples extensiones que permiten facilitar las pruebas en en-
tornos o situaciones específicas. Por ejemplo, Jasmine-JQuery [23] ofrece una serie de
facilidades para realizar pruebas sobre elementos del DOM y eventos asociados a ellos.
Otra de las extensiones interesantes para Jasmine es Istanbul [24], que proporciona cober-
tura del código, es decir, informa al desarrollador de qué zonas del código están siendo
ejecutadas en las pruebas.
2.8.2 Karma
Karma [26] es esencialmente una herramienta que lanza un servidor cada vez que se
ejecuta. En ese servidor se ejecutarán los tests especificados en el fichero de configuración
usando el framework de testing especificado (por ejemplo, Jasmine).
Karma es especialmente útil para funciones de debugging ya que permite mantener el
servidor vivo mientras se realiza el debugging del código.
Además, Karma permite la ejecución de las pruebas en diferentes navegadores web
para conseguir una compatibilidad completa en la aplicación desarrollada.
2.9 Integración continua
La integración continua [14] es un modelo que consiste en hacer integraciones auto-
máticas de un proyecto lo más a menudo posible para detectar fallo a la mayor brevedad.
Una integración es la compilación y ejecución de todas las pruebas de un proyecto.
La integración continua tiene múltiples ventajas como permitir detectar fallos a tiempo
y evitar así el caos cuando se acercan las fechas de entrega, la disponibilidad constante de
una versión para pruebas o demos, o la monitorización continua de las métricas de calidad
de un proyecto.
28
CAPÍTULO 2. ESTADO DEL ARTE
2.9.1 Jenkins
Jenkins [15] es un software de integración continua escrito en Java que ha sido muy
exitoso entre los desarrolladores. El proyecto es de código abierto y está basado en el
anterior proyecto Hudson desarrollado por Sun Microsystems en 2005.
Jenkins tiene soporte para software de control de versiones como Git, Mercurial o
Subversion y además puede ejecutar scripts Bash (Linux) o Batch (Windows).
2.10 Grunt
Grunt [25] es un automatizador de tareas para JavaScript que permite realizar me-
diante sencillo comandos tareas repetitivas como minificación, concatenación, testing o
corrección sintáctica.
Esto se consigue a través de distintos módulos de Grunt que crean una tarea que luego
se puede añadir al fichero de configuración de grunt llamado Gruntfile. A partir de ese
momento las tareas se pueden invocar desde consola ejecutando el comando grunt seguido
del nombre de la tarea.
29
CAPÍTULO 2. ESTADO DEL ARTE
30
Capítulo 3
DESARROLLO
A lo largo de este capítulo se describirán las tareas llevadas a cabo durante este Trabajo
de Fin de Grado. Con el objetivo de facilitar el entendimiento de la estructura del capítulo,
se procede a explicar la misma de manera breve.
El capítulo constará de un apartado por cada componente desarrollado durante el Tra-
bajo de Fin de Grado. Así mismo, cada apartado contendrá una subsección por cada
widget desarrollado para el componente. Por último, la explicación del desarrollo de cada
widget estará estructurada en las siguientes partes: desarrollo de funcionalidades y análisis
de casos de uso.
Las únicas excepciones a lo anteriormente explicado son los apartados que explican
el desarrollo de la autenticación contra el servicio Keystone integrada en la plataforma
WireCloud, ya que para completar este componente no fue necesaria la creación de ningún
widget sino la adición de una librería a la plataforma.
Los casos de uso utilizados para cada widget como base para diseñar el conjunto de
pruebas unitarias utilizado, se explicarán en un apartado de cada widget utilizando el
estilo de representación de tests Given/When/Then traduciendo a los siguientes términos
en español Dado/Cuando/Entonces.
Por último, cabe resaltar que la interfaz gráfica creada para los distintos widgets tenía
como objetivo principal ser simple y entendible a la vez que conservadora con el espacio
utilizado ya que se pretende que los usuario no necesiten tener resoluciones muy altas
para poder visualizar todo el dashboard en su pantalla.
31
CAPÍTULO 3. DESARROLLO
3.1 Librerías de funcionalidades comunes a varios widgets
Algunas funcionalidades han sido implementadas en varios widgets que tienen objeti-
vos parecidos pero que varían en el tipo de recurso que gestionan, por ejemplo hay tres
widgets de tablas usados para listar todos los recursos disponibles de un determinado tipo
y estos tres tienen funcionalidades básicas compartidas entre ellos (por ejemplo el sistema
de paginación). Estas funcionalidades forman parte de librerías realizadas en el ámbito de
este Trabajo de Fin de Grado con el objetivo de evitar la repetición de código, y serán
descritas detalladamente en su propio apartado con el fin hacer la memoria más legible al
no repetir las mismas descripciones.
3.1.1 Librería de widgets de listado de recursos
Esta librería contiene todas las funcionalidades compartidas entre los widgets de lis-
tado de recursos de un mismo tipo, ya sean imágenes, volúmenes o instancias. En este
apartado se describirán claramente las funcionalidades desarrolladas en esta librería que
es usada por tres widgets cuyas funcionalidades específicas serán apropiadamente descri-
tas en apartados posteriores.
Funcionalidades desarrolladas
A continuación se describen las funcionalidades desarrolladas para esta librería indi-
cando tanto su objetivo como algunos detalles importantes de su implementación.
1. Autenticación temporal contra el servicio Keystone
ObjetivoDebido a que la opción de implementar la autenticación integrada en la plata-
forma WireCloud no estuvo disponible desde el principio del Trabajo de Fin
de Grado, se optó por implementar una autenticación contra el servicio Keys-
tone en el propio widget.
El objetivo de dicha autenticación es obtener un token que permita al widgethacer uso de los servicios de OpenStack.
ImplementaciónLa autenticación esta basada en el sistema de gestión de identidades que ofre-
ce la instalación de OpenStack a través del servicio Keystone. En el caso de
32
CAPÍTULO 3. DESARROLLO
FIWARE Lab existe un único servidor de Keystone para todas las regiones y
en cada una de ellas existe un proxy para acceder al servidor único.
Por tanto, el token de servicios se obtiene mediante de una llamada al servidor
de Keystone del portal de cloud de FIWARE a través del proxy de WireCloud
primero para obtener el token identificador del usuario, y del proxy de la re-
gión en la que se encuentre el usuario posteriormente para acceder al servidor
único de Keystone.
Cabe destacar que la funcionalidad de los widgets para cada usuario está sujeta
a los permisos que tenga este en cada región.
2. Hacer actualizaciones automatizadas de contenido
ObjetivoEl usuario debe poder ver los últimos cambios en los contenidos de su clouden tiempo real sin necesidad de pulsar un botón de actualizar, lo cual puede
hacerse tedioso. Esto es especialmente útil para los casos en que la funciona-
lidad de un widget afecta a los elementos gestionados por otro, por ejemplo,
al borrar el recurso que se tenga seleccionado en el widget de visualización
detallada de un recurso (ya sean imágenes, instancias o volúmenes), este se
borrara de la lista sin que el usuario tenga que actualizar manualmente.
ImplementaciónCada vez que se recibe la respuesta a una petición de obtención del listado de
los elementos disponibles del tipo recurso gestionado por el widget, se inicia
una cuenta atrás de cuatro segundos. Al finalizar esta cuenta atrás, se una
nueva petición de obtención del listado de elementos del tipo concreto que
gestiona el widget.
3. Fijar la posición de las cabeceras de la tabla
ObjetivoLas cabeceras de la tabla muestran al usuario cuál es el contenido de una de-
terminada columna, y cada columna representa un atributo del tipo de recurso
que gestiona el widget, sean volúmenes, instancias o imágenes. Por tanto, el
usuario debe poder ver en todo momento las cabeceras de la tabla para ser
consciente de qué es lo que está leyendo en cada columna, en caso contra-
rio, se le forzaría a memorizar el atributo mostrado en cada columna, lo cual
no es viable de por sí y menos en una tabla en la que es posible cambiar la
disposición de las columnas.
33
CAPÍTULO 3. DESARROLLO
ImplementaciónSe ha hecho uso de la extensión de DataTables, FixedHeader, que coloca la
primera fila de la tabla (las cabeceras) siempre por encima de los otros ele-
mentos de la interfaz. En la Figura 3.1 puede verse el aspecto de la cabecera
con su posición fijada.
4. Fijar la posición de la barra inferior
ObjetivoLa barra inferior contiene los botones de paginación, creación de imágenes y
el campo de búsquedas, por tanto sería muy incómodo para el usuario despla-
zarse hasta el último elemento de la tabla cada vez que quisiera hacer uso de
estas funcionalidades.
ImplementaciónSe ha establecido la posición de la barra inferior como fija con respecto a los
bordes del widget, de esta manera se consigue que el usuario siempre tenga
acceso a las funcionalidades que se ofrecen en dicha barra. En la Figura 3.1
puede verse el aspecto de la barra inferior con su posición fijada.
Figura 3.1: Vista de un widget de tablas
5. Buscar elementos en la tabla
ObjetivoEn los casos en que un usuario tenga disponibles muchos elementos puede
ser muy frustrante buscar uno en concreto. Para solucionar este problema se
incluye una barra de búsqueda que dibuje en la tabla sólo los elementos que
coincidan total o parcialmente con lo escrito en la barra de búsqueda.
34
CAPÍTULO 3. DESARROLLO
ImplementaciónSe ha utilizado la propia funcionalidad de búsqueda de la librería DataTables
para implementar esta funcionalidad. El usuario puede pulsar un botón en la
barra inferior que muestra el campo de búsqueda con una animación. Se ha
implementado de tal manera que el contenido de la tabla se actualice cada vez
que el usuario escribe un carácter en el campo de búsqueda. En la Figura 3.2 se
puede aprecial cómo al introducir caracteres en la barra de búsqueda la tabla
solo muestra las entradas que coincidan.
Figura 3.2: Funcionamiento de la búsqueda en la tabla
6. Sistema de paginación
ObjetivoCuando hay muchos elementos disponibles, desplazarse hacia abajo con el
ratón para verlos todos, puede hacerse tedioso para el usuario, por tanto hay
que hacer un sistema de paginación para poder dividir el conjunto de elemen-
tos (ya sean imágenes, instancias o volúmenes) en secciones más pequeñas y
manejables para el usuario.
ImplementaciónSe ha utilizado el sistema de paginación integrado en la librería DataTables
para facilitar la implementación de la paginación en el widget. En la barra in-
ferior se permite desplazarse a la siguiente página, la anterior, la primera, o la
última. También se le facilita al usuario la opción de ir a la página que prefie-
ra. Tanto en la Figura 3.1 como en la Figura 3.2 puede verse cómo el sistema
de paginación se adapta al número de elementos mostrados deshabilitando
35
CAPÍTULO 3. DESARROLLO
botones y cambiando las páginas mostradas.
7. Permitir al usuario elegir los atributos que se muestran en la tabla
ObjetivoSe debe permitir al usuario elegir qué atributos del tipo de recurso mostrado
deben mostrarse en la tabla. Cada atributo se visualiza como una columna de
la tabla, y de esta manera el usuario puede tener a la vista aquellos atributos
que le resulten más útiles.
ImplementaciónEsta funcionalidad se implementa usando el sistema de preferencias de cada
widget de la plataforma WireCloud. Mediante este sistema se pueden definir
preferencias totalmente personalizadas y luego recibir eventos cuando alguna
preferencia cambia. En este caso, se ha añadido un campo de checkbox por
cada atributo presente en un tipo de recurso (ya sean atributos de imágenes,
instancias o volúmenes) para que el usuario pueda elegir todos aquellos que
quiere mostrar.
8. Mostrar los errores producidos en las llamadas a OpenStack
ObjetivoSe debe mantener informado al usuario sobre el estado de sus recursos y esto
incluye mostrarle cuándo no se han podido realizar las operaciones que ha so-
licitado. Para esto, es necesario tener un sistema de errores unificado que sirva
para mostrar todos los tipos de errores de manera fácilmente comprensible
para el usuario.
ImplementaciónLos errores se muestran a través un mensaje de alerta que aparece en la tabla.
El mensaje cambia según el código del error y permite mostrar el mensaje
de error original recibido del servicio concreto de OpenStack a través de un
botón de ’detalles’. Si el widget no reconoce el mensaje se muestra el mensaje
original recibido. En la figura Figura 3.3 se muestra un ejemplo de error.
Figura 3.3: Error mostrado en la tabla
36
CAPÍTULO 3. DESARROLLO
9. Permitir la gestión de múltiples regiones simultáneamente
ObjetivoLas regiones en FIWARE están definidas utilizando instalaciones de OpenStack
federadas, es decir, no están todas en una misma instalación. Por tanto, el usua-
rio debe poder acceder y gestionar sus recursos en todas las regiones del Cloud
de FIWARE como si se tratase de una sola instalación.
ImplementaciónAl disponer de una instancia de Keystone centralizada que devuelve en su
catálogo de servicios los endpoints de todos los servicios en las distintas re-
giones, se ha podido acceder a las direcciones de todas las regiones a través de
una sola llamada a Keystone. A partir de ahí se ha implementado una interfaz
mínima y simple para que el usuario pueda elegir tantas regiones como desee
ver y estas puedan verse en la tabla automáticamente. Se puede desplegar el
menú de selección de regiones utilizando el botón con el icono del globo terrá-
queo de la barra inferior del widget. En la Figura 3.4 se puede ver el selector
de regiones y su ubicación en la interfaz.
Figura 3.4: Menú de selección de regiones
3.1.2 Librería de widgets de visualización detallada de un recurso
Esta librería contiene las funcionalidades comunes a todos los widgets destinados a
mostrar de manera detallada los atributos de un determinado recurso (una imagen, una
instancia o un volumen). A continuación, se describirán detalladamente todas aquellas
37
CAPÍTULO 3. DESARROLLO
funcionalidades que son comunes a varios widgets de este tipo, el resto de ellas serán
descritas en apartados posteriores específicos de cada widget.
Funcionalidades desarrolladas
A continuación se describen las funcionalidades desarrolladas para esta librería indi-
cando tanto su objetivo como algunos detalles importantes de su implementación.
1. Actualización automática de los datos de la imagen
ObjetivoEl usuario debe poder ver los últimos cambios en los parámetros de su imagen
en tiempo real sin necesidad de pulsar un botón de actualizar, lo cual puede
hacerse tedioso. Esto es especialmente útil para el borrado de imágenes ya que
permite al widget dejar de mostrar la imagen una vez se ha borrado sin que el
usuario se vea forzado a actualizar manualmente.
ImplementaciónCada vez que se recibe la respuesta a la obtención de imágenes se inicia una
cuenta atrás de dos segundos. Al finalizar esta cuenta atrás, se llama de nuevo
a la función de obtener la lista de imágenes. En el caso de que el estado de
la imagen indique que se está realizando alguna operación con ella, se reduce
automáticamente el tiempo de refresco a un segundo ya que en estos casos, al
estar ocurriendo cambios en el estado de la imagen, se requiere un seguimiento
lo más cercano posible al tiempo real.
2. Mostrar errores recibidos en la interfaz
ObjetivoSe debe mantener informado al usuario sobre el estado de sus recursos y esto
incluye mostrarle cuando no se han podido realizar las operaciones que ha so-
licitado. Para esto, es necesario tener un sistema de errores unificado que sirva
para mostrar todos los tipos de errores de manera fácilmente comprensible
para el usuario.
ImplementaciónLos errores se muestran a través un mensaje de alerta que aparece en la interfaz
del widget. El mensaje cambia según el código del error y permite mostrar el
mensaje de error original recibido del servicio concreto de OpenStack a través
de un botón de ’detalles’. Si el widget no reconoce el mensaje se muestra el
38
CAPÍTULO 3. DESARROLLO
mensaje original recibido.
3.2 Componente de gestión de imágenes
El componente de imágenes consta de dos widgets. El primero muestra en una tabla las
imágenes disponibles para un usuario y el segundo muestra los parámetros de la imagen
seleccionada en la tabla. Ambos permiten, otras acciones como crear o borrar imágenes
que serán descritas a continuación.
3.2.1 Widget de listado de imágenes
Este widget tiene por objetivo ofrecer al usuario una vista conjunta en forma de tabla
de todas las imágenes que tiene disponibles, a la vez que muestra algunos de sus datos en
la tabla. Los datos de cada imagen que se muestran en la tabla pueden ser elegidos por el
usuario a través de las opciones de configuración de widget ofrecidas por la plataforma
WireCloud.
Desarrollo de funcionalidades
En esta sección se describen los requisitos funcionales de los que se partieron para
implementar el widget, y además se ofrece una explicación de cómo se ha desarrollado
cada uno de ellos.
1. Obtener una lista de todas las imágenes disponibles y pintarlas en la tabla
ObjetivoEs la principal función del widget. Se necesita obtener la lista de todas las imá-
genes a través de la API del servicio Glance de OpenStack y a continuación
pintar dichas imágenes en la tabla del widget.
ImplementaciónPara realizar las llamadas a la API del servicio Glance, se ha utilizado la libre-
ría JStack que ofrece una interfaz para realizar llamadas Ajax a los distintos
servicios de OpenStack. Como resultado de esta llamada se obtiene un objeto
con estructura JSON que contiene la lista de imágenes. Utilizando este objeto
JSON se dibujan las imágenes recibidas en la tabla del widget, de manera que
cada imagen es una fila y cada campo mostrado es un parámetro de la imagen.
39
CAPÍTULO 3. DESARROLLO
2. Crear una imagen
ObjetivoSe debe permitir al usuario crear una imagen y establecer todos los parámetros
relevantes para la creación de la misma. Esto es útil cuando el usuario pretende
desplegar una instancia con una imagen personalizada o distribuida por un
tercero y que, por tanto, no está entre las imágenes públicas ofrecidas por el
cloud.
ImplementaciónPara crear una nueva imagen, se ha dispuesto un formulario al que se puede
acceder pulsando un botón en la barra inferior del widget. La creación de
imágenes se lleva a cabo mediante una llamada HTTP POST a la API del
servicio Glance de OpenStack. Todos los parámetros necesarios para realizar
esta llamada se obtienen del formulario que el usuario debe rellenar. El usuario
debe elegir si quiere subir su propia imagen al servidor o descargarla desde una
URL externa. Ambas opciones están disponibles para el usuario, aunque solo
puede elegir una de las dos. En la Figura 3.5 puede verse el aspecto de este
formulario.
Figura 3.5: Formulario de creación de una imagen
3. Lanzar una instancia a partir de la imagen de la tabla del widget
40
CAPÍTULO 3. DESARROLLO
ObjetivoPermite al usuario lanzar una nueva instancia a partir de una imagen de la
tabla, pudiendo elegir este todos los parámetros necesarios para crear la ins-
tancia.
ImplementaciónEl usuario accede a esta funcionalidad a través de botones situados en cada
una de las filas (imágenes) de la tabla. Esto abre un formulario que permite
al usuario rellenar los campos relevantes para la creación de la instancia. Este
no es el único lugar del dashboard desde el que un usuario puede crear una
instancia.
4. Enviar la id del la imagen seleccionada en la tabla a los otros widgets interesados
ObjetivoCuando el usuario haga click en una imagen de la tabla se espera que ocurra
algún cambio en los widgets conectados a este a través de las conexiones de
WireCloud. En este caso el evento debe consistir en enviar la id de la imagen
seleccionada a todos los widgets conectados a este.
ImplementaciónSe utiliza la API de WireCloud para enviar un evento que contenga la id de la
imagen seleccionada a los demás widgets conectados.
Casos de uso
Escenario 1 Obtención de la lista de imágenes
Dado un usuario que tiene cuatro imágenes disponibles en una instancia de OpenStack
Cuando el widget hace la llamada de obtención de imágenes
Entonces recibe una cadena de texto en formato JSON que incluya las cuatro imá-
genes
Escenario 2 Dibujar las imágenes en la tabla
Dado un widget que ha pedido todas las imágenes disponibles para el usuario en
OpenStack
Cuando reciba las imágenes correctamente en forma de cadena de texto JSON
Entonces dibuja los datos relevantes de las imágenes en la tabla del widget
41
CAPÍTULO 3. DESARROLLO
Escenario 3 Actualizar el contenido de la tabla automáticamente
Dado un widget que ha recibido una lista de imágenes
Cuando pasa un determinado número de segundos
Entonces se realiza otra petición de la lista de imágenes
Escenario 4 Mostrar las columnas elegidas en las preferencias
Dado un widget que está mostrando una lista de imágenes en la tabla
Cuando el usuario cambia las preferencias seleccionando mostrar otros parámetros
de las imágenes
Entonces la tabla debe mostrar los parámetros seleccionados por el usuario como
columnas de dicha tabla
Escenario 5 Crear una imagen a partir de un archivo local
Dado un usuario en posesión de un archivo de imágen
Cuando el usuario rellena y envía el formulario de creación de imagen seleccio-
nando su archivo de imagen local
Entonces el widget sube la imagen a OpenStack
Y allí se crea una nueva imagen que el usuario puede visualizar en la tabla del
propio widget
Escenario 6 Crear una imagen a partir de un archivo de imagen remoto
Dado un usuario que quiere crear una imagen proveída por un tercero
Cuando el usuario rellena y envía el formulario de creación de imagen e indica la
URL del archivo de imagen remoto
Entonces OpenStack descarga el archivo de imagen desde el servidor remoto
Y se crea una nueva imagen que el usuario puede visualizar en la tabla del propio
widget
Escenario 7 Mostrar los errores en la interfaz del widget
Dado un widget que hace una petición a un servicio de OpenStack
Cuando el servicio devuelve un error
42
CAPÍTULO 3. DESARROLLO
Entonces el widget muestra el error en la interfaz gráfica en forma de mensaje de
alerta
Escenario 8 Mostrar en la tabla las imágenes que coincidan con la búsqueda
Dado un usuario que quiere encontrar una imagen concreta en una tabla
Cuando el usuario introduce su criterio de búsqueda en el campo apropiado
Entonces la tabla sólo muestra las imágenes que coinciden con el criterio de bús-
queda introducido por el usuario
Escenario 9 Enviar la ID de la imagen seleccionada a través del endpoint de salida co-
rrespondiente
Dado un widget que muestra una tabla con imágenes
Cuando el usuario hace click con el ratón sobre una imagen de la tabla
Entonces el widget envía un evento por el endpoint de salida apropiado que con-
tiene la ID de la imagen seleccionada
3.2.2 Widget de detalles de imagen
Este widget tiene por objetivo mostrar todos los parámetros de una imagen de una
forma atractiva y legible para el usuario. Además, incorpora otras funcionalidades como
el borrado o la edición de imágenes. El widget solo empieza a mostrar una imagen una
vez recibe su ID mediante su endpoint de entrada, ya sea proveniente del widget de listado
de imágenes explicado anteriormente u otro.
Desarrollo de funcionalidades
En esta sección se describen los requisitos funcionales de los que se partieron para
implementar el widget, y además se ofrece una explicación de cómo se ha desarrollado
cada uno de ellos.
1. Recibir la ID de la imagen
ObjetivoA través del endpoint de entrada, el widget recibe las ID de una imagen. Usan-
do este ID, el widget puede conseguir los parámetros de la imagen. La recep-
43
CAPÍTULO 3. DESARROLLO
ción de una ID de imagen debería disparar un evento para obtener los datos de
la imagen.
ImplementaciónSe ha usado la API del editor de conexiones de WireCloud para definir el
evento de recibir una ID y asignarle un callback que obtenga los datos de la
imagen correspondiente a dicha ID.
2. Obtener los detalles de la imagen del servicio Glance de OpenStack y dibujarlos
ObjetivoEs el objetivo principal del widget y permite que el usuario pueda ver todos
los parámetros de la imágenes que pueden ser útiles para comprobar fechas de
creación y modificación, tamaño, formato de disco y otros.
ImplementaciónSe utiliza el servicio Glance de OpenStack para acceder a los datos de una
imagen aportandole su ID como parámetro. La llamada a Glance se realiza a
través de la librería JStack que proporciona una interfaz para realizar llamadas
a las distintas APIs de OpenStack. En la Figura 3.10 se muestra el aspecto de
la vista de detalles de una imagen.
Figura 3.6: Vista de detalles del widget
3. Borrado de imágenes
ObjetivoDebe hacerse posible para un usuario borrar una imagen que haya creado él
mismo o que no esté protegida. Esto permite a un usuario deshacerse de imá-
genes erróneas que haya creado o de imágenes que simplemente ya no le re-
sultan útiles. El usuario no debe ser capaz de borrar la imagen si esta no es
suya a no se que no esté protegida.
44
CAPÍTULO 3. DESARROLLO
ImplementaciónSe utiliza una llamada al servicio Glance para borrar una imagen, proporcio-
nándole su ID para identificarla correctamente. El widget lee de los parámetros
de la imagen si el dueño de la misma es el propio usuario y si está protegida y
actua en consecuencia habilitando o deshabilitando el botón de borrar situado
en el desplegable .Actions" en la barra superior de la interfaz. Una vez recibida
la confirmación de OpenStack de que la imagen ha sido en efecto borrada,
el widget vuelve a mostrar su vista por defecto y desaparece la vista de los
detalles de la imagen.
4. Mostrar estado de la imagen mediante icono
ObjetivoEs importante para el usuario ser consciente en todo momento del estado de
la imagen ya que podría afectar a sus decisiones sobre el uso que va a hacer
de la misma. Por ello, el estado de la imagen debe aparecer en un lugar clara-
mente visible de la interfaz y separado de los otros parámetros. Una imagen
en OpenStack tiene tres estados posible: ACTIVE, QUEUED y SAVING, cada
uno de ellos debe mostrarse en la interfaz con un icono distinto que permita al
usuario distinguirlos inequívocamente.
ImplementaciónLos tres estados posibles de la imagen están representados por un icono so-
bre un cuadro de un color distinto dependiendo de lo que quiera transmitir el
estado, por ejemplo, el estado ACTIVE, tiene como icono un tic dentro de un
cuadrado verde. En la Figura 3.7 se muestra un ejemplo de icono de estado de
una imagen.
Figura 3.7: Estado AVAILABLE
5. Edición de los parámetros de una imagen
ObjetivoEl usuario debe ser capaz de modificar los parámetros de una imagen por si se
diera el caso que necesitara hacer alguna modificación en la imagen original,
ya sea por haber elegido el archivo de imagen incorrecto al crearla o haberle
45
CAPÍTULO 3. DESARROLLO
puesto un nombre incorrecto o cualquier otro de los parámetros que sea posi-
ble modificar. Se considera que los siguientes parámetros deben ser editables:
nombre de imagen, dirección del archivo de imagen (sea este local o remoto),
el formato de disco, el formato de imagen, la visibilidad, la protección y los
mínimos de RAM y disco consumidos.
ImplementaciónSe ha incluido un botón de edición de imagen en el desplegable .Actions" de la
barra superior del widget. Este botón despliega un formulario de edición en el
que se muestran todos los parámetros de la imagen que se pueden editar (ya
listados en la sección de objetivos). En la Figura 3.8 se muestra el aspecto de
dicho formulario.
Figura 3.8: Formulario de edición de una imagen
Casos de uso
Escenario 1 Recibir la ID de una imagen a través del sistema de conexiones de WireCloud
Dado un widget de detalles de imagen que no ha recibido una ID de imagen aún
Cuando recibe una ID de imagen
Entonces llama a la API del servicio Glance de OpenStack para obtener los datos
de la imagen correspondiente a la ID recibida
Escenario 2 Obtener y dibujar los parámetros de la imagen
46
CAPÍTULO 3. DESARROLLO
Dado un widget de detalles de imagen que ha recibido una ID de imagen
Cuando se hace la llamada a la API de Glance
Entonces se obtienen los datos de la imagen y se pintan en la interfaz del widget
Escenario 3 Actualizar los datos del widget mostrando una imagen en estado ACTIVE
Dado un widget de detalles de imagen mostrando los parámetros de una imagen
con estado ACTIVE
Cuando pasan cuatro segundos desde la última vez que se recibió una actualiza-
ción de los datos de la imagen
Entonces se envía otra petición para obtener los datos de la imagen
Escenario 4 Actualizar los datos del widget mostrando una imagen con un estado distinto
de ACTIVE
Dado un widget de detalles de imagen mostrando los parámetros de una imagen
con estado distinto de ACTIVE
Cuando pasa un segundo desde la última vez que se recibió una actualización de
los datos de la imagen
Entonces se envía otra petición para obtener los datos de la imagen
Escenario 5 Borrar una imagen
Dado un widget de detalles que está mostrando los detalles de una imagen
Cuando el usuario haga click en el botón de borrar imagen
Entonces el widget enviará una petición a la API de Glance para borrar la imagen
Y dejará de mostrar la imagen en la interfaz para volver a la vista por defecto a la
espera de una nueva imagen
Escenario 6 Cambiar un parámetro de una imagen
Dado una imagen mostrada en el widget de detalles
Cuando el usuario modifique uno o más parámetros en el formulario de edición de
la imagen
Entonces el widget debe enviar una petición a la API de Glance para modificar los
parametros cambiados
Escenario 7 Mostrar los errores devueltos en la interfaz
47
CAPÍTULO 3. DESARROLLO
Dado una petición a la API de OpenStack por parte del widget
Cuando se produce un error y el servidor de OpenStack te devuelve un mensaje de
error
Entonces el widget debe mostrar el error correctamente haciendo uso del sistema
de errores
3.3 Componente de gestión de instancias
Este componente, al igual que el anterior, consta de dos widgets. El primero tiene como
utilidad principal permitir al usuario visualizar sus instancias y algunos de sus atributos
y el segundo, mostrar dichos atributos de una manera mucho más detallada y vistosa a la
vez que permite al usuario realizar otras operaciones sobre la instancia elegida.
3.3.1 Widget de listado de instancias
Este widget tiene como principal utilidad mostrar al usuario sus instancias (máquinas
virtuales) en el cloud. Es además un visor completo que permite realizar búsquedas de
instancias concretas y mostrar los atributos que se deseen de una determinada instancia.
A continuación, se describen las funcionalidades desarrolladas para este widget así como
los casos de uso utilizados para realizar las pruebas unitarias.
Funcionalidades desarrolladas
En esta sección se describen todas las funcionalidades desarrolladas para este widget,así como los detalles relevantes de su implementación.
1. Obtener una lista de todas las instancias disponibles y pintarlas en la tabla
ObjetivoEsta es la funcionalidad principal del widget. Se debe obtener un listado de
todas las instancias pertenecientes al usuario y a continuación dibujarlo en
una tabla en la que cada fila será una instancia concreta y cada columna un
atributo de dicha instancia.
ImplementaciónEl servicio Nova es el que ofrece funcionalidades de cómputo en OpenStack y,
48
CAPÍTULO 3. DESARROLLO
por tanto, es el que se utiliza para listar las instancias de un usuario. Para rea-
lizar las llamadas a la API del servicio Nova, se ha utilizado la librería JStack
que ofrece una interfaz para realizar llamadas Ajax a los distintos servicios de
OpenStack. Como resultado de esta llamada se obtiene un objeto con estruc-
tura JSON que contiene la lista de instancias. Utilizando este objeto JSON se
dibujan las instancias recibidas en la tabla del widget, de manera que cada fila
es una instancia y cada campo mostrado es un atributo de la instancia.
2. Crear una nueva instancia
ObjetivoSe debe permitir al usuario crear y arrancar una instancia estableciendo todos
los parámetros relevantes para la creación de la misma. Las instancias son
máquinas virtuales y estas son la principal utilidad de un cloud ya que en ellas
se pueden desplegar servidores de aplicaciones. Por tanto es primordial para
un dashboard permitir al usuario crear sus propias instancias de con todas las
opciones de personalización ofrecidas por OpenStack.
ImplementaciónPara crear una nueva instancia, se ha dispuesto un formulario al que se pue-
de acceder pulsando el botón con el icono de ’más’ (+) en la barra inferior
del widget. La creación de instancias se lleva a cabo mediante una petición
POST a la API del servicio Nova de OpenStack. Todos los parámetros ne-
cesarios para realizar esta petición se obtienen del formulario que el usuario
debe rellenar. El usuario debe poder elegir a partir de qué imagen va a crear la
instancia así como otros parámetros de gran importancia como las claves que
se utilizarán para acceder vía SSH a la máquina una vez creada, o las opciones
de seguridad de puertos de la misma. También debe ser posible elegir el flavor
de la instancia, que no es más que una medida de la cantidad de recursos que
necesitará (RAM, disco duro, VCPUs, etc.). en la Figura 3.9 se puede ver el
formulario de creación de una instancia.
3. Enviar la ID de la instancia seleccionada mediante el sistema de conexiones de
WireCloud
ObjetivoCuando el usuario haga click en una instancia de la tabla se debe enviar un
evento con información sobre la instancia seleccionada. En este caso el evento
debe consistir en enviar la ID de la instancia seleccionada a todos los widgetsconectados a este.
49
CAPÍTULO 3. DESARROLLO
Figura 3.9: Formulario de creación de una instancia
ImplementaciónSe utiliza la API de WireCloud para enviar un evento, que contenga la id de la
instancia seleccionada, a través del endpoint de salida hacia cualquier widgetque que tenga un endpoint de entrada conectado a este.
Análisis de casos de uso
Escenario 1 Obtención de la lista de instancias
Dado un usuario que tiene dos instancias disponibles en un cloud OpenStack
Cuando el widget hace la llamada de obtención de instancias
Entonces recibe una cadena de texto en formato JSON que incluya las dos instan-
cias así como información adicional sobre cada una de ellas
Escenario 2 Dibujar las instancias en la tabla
Dado un widget que ha pedido todas las instancias pertenecientes a un usuario de
OpenStack
Cuando reciba las instancias correctamente en forma de cadena de texto JSON
Entonces dibuja en la tabla del widget los datos relevantes de las instancias que
hayan sido elegidos por el usuario en las preferencias
50
CAPÍTULO 3. DESARROLLO
Escenario 3 Actualizar el contenido de la tabla automáticamente
Dado un widget que ha recibido una lista de instancias
Cuando pasan cuatro segundos
Entonces se realiza otra petición de obtención de la lista de instancias
Escenario 4 Mostrar las columnas elegidas en las preferencias
Dado un widget que está mostrando una lista de instancias en la tabla
Cuando el usuario cambia las preferencias seleccionando mostrar otros atributos
de las instancias
Entonces la tabla debe mostrar los atributos seleccionados por el usuario como
columnas de dicha tabla
Escenario 5 Crear una instancia
Dado un usuario que necesita crear una instancia
Cuando el usuario rellena y envía el formulario de creación de una instancia
Entonces el widget envía la petición POST al servicio Nova de OpenStack y en el
lado servidor se crea la nueva instancia y comienza su despliegue
Escenario 7 Mostrar los errores en la interfaz del widget
Dado un widget que hace una petición a un servicio de OpenStack
Cuando el servicio devuelve un error
Entonces el widget muestra el error en la interfaz gráfica en forma de mensaje de
alerta
Escenario 8 Mostrar en la tabla las instancias que coincidan con la búsqueda
Dado un usuario que quiere encontrar una instancia concreta en una tabla
Cuando el usuario introduce su criterio de búsqueda en el campo apropiado de la
barra inferior
Entonces la tabla sólo muestra las instancias que coinciden con el criterio de bús-
queda introducido por el usuario
Escenario 9 Enviar la ID de la instancia seleccionada a través del endpoint de salida
correspondiente
51
CAPÍTULO 3. DESARROLLO
Dado un widget que muestra una tabla con las instancias de un usuario
Cuando el usuario hace click con el ratón sobre una instancia de la tabla
Entonces el widget envía un evento por el endpoint de salida apropiado que con-
tiene la ID de la instancia seleccionada
3.3.2 Widget de detalles de instancias
Este widget tiene por objetivo mostrar todos los parámetros de una instancia de una
forma atractiva y legible para el usuario. Además, incorpora otras funcionalidades como
el borrado, la edición o el reinicio de instancias. El widget solo empieza a mostrar una
instancia una vez recibe su ID mediante su endpoint de entrada, ya sea proveniente del
widget de listado de instancias explicado anteriormente u otro. En este apartado se explica
detalladamente el desarrollo de todas las funcionalidades llevadas a cabo en este widget.Además, se detallan los casos de uso utilizados como base para realizar las pruebas uni-
tarias llevadas a cabo con el fin de asegurar su correcto funcionamiento.
Funcionalidades desarrolladas
En esta sección se describen todas las funcionalidades desarrolladas para este widget,así como los detalles relevantes de su implementación.
1. Recibir la ID de la instancia
ObjetivoA través del endpoint de entrada, el widget recibe el ID de una instancia.
Usando este ID, el widget puede conseguir los atributos de la instancia. La
recepción de un ID de instancia debería disparar un evento para obtener sus
datos.
ImplementaciónSe ha usado la API del editor de conexiones de WireCloud para definir el
evento de recibir un ID y asignarle un callback que obtenga los datos de la
imagen correspondiente a dicho ID.
2. Obtener los detalles de la instancia del servicio Nova de OpenStack y dibujarlos
ObjetivoCuando el widget recibe un nuevo evento del sistema de conexiones acompa-
52
CAPÍTULO 3. DESARROLLO
ñado de un nuevo ID de instancia, debe usar este ID para obtener los datos
de la instancia del servidor de OpenStack y pintar los datos obtenidos en la
interfaz del widget.
ImplementaciónSe utiliza el servicio Nova de OpenStack para acceder a los datos de una ins-
tancia aportándole su ID como parámetro. La llamada a Nova se realiza a tra-
vés de la librería JStack que proporciona una interfaz para realizar llamadas a
las distintas APIs de OpenStack. En la Figura 3.10 se puede ver el aspecto de
la interfaz del widget en la vista de detalles.
Figura 3.10: Widget de detalles de instancia
3. Borrado de una instancia
ObjetivoEl usuario debe ser capaz de borrar una instancia cuando lo desee. Esta fun-
cionalidad permite al usuario borrar instancias que hayan sido creadas con
errores o simplemente lanzadas a partir de la imagen incorrecta. Un usuario
de OpenStack solo debe poder borrar instancias que sean suyas y que no estén
realizando alguna otra tarea en ese momento, por ejemplo no se puede borrar
una máquina virtual que esté en proceso de creación o de reinicio.
ImplementaciónSe ha añadido un botón de borrar en el desplegable .Actions" de la barra supe-
rior del widget que permite al usuario terminar una instancia (borrarla) siem-
pre que ésta se encuentre en el estado adecuado y no esté realizando alguna
tarea en ese momento. El borrado de la instancia se lleva a cabo a través de la
función de borrado de instancia del servicio Nova de OpenStack.
53
CAPÍTULO 3. DESARROLLO
4. Reinicio de una instancia
ObjetivoSe debe permitir al usuario realizar un reinicio software de la máquina virtual
desde la interfaz del widget. Esta funcionalidad es necesaria para que el usua-
rio pueda finalizar actualizaciones de sistema operativo que puedan requerir
un reinicio de la máquina (la instancia) para completarse.
ImplementaciónSe ha añadido un botón de reinicio de la instancia en el desplegable .Actions"de la barra superior del widget, que facilita al usuario iniciar el proceso de
reinicio de la instancia. El progreso de dicho reinicio se va mostrando en la
interfaz del widget a través de diversos cambios de estado y también cambios
en las tareas que está realizando la instancia en cada momento que harán saber
al usuario si el reinicio se ha llevado a cabo correctamente.
5. Mostrar el estado de una instancia mediante icono
ObjetivoLas instancias de OpenStack tienen un estado un tanto más complejo que el
de los otros recursos manejados. Tiene en total tres tipos de estado distintos:
el estado de la instancia, el estado de la máquina virtual y el llamado power
state, que diferencia estados de arranque del a máquina. Además, las instan-
cias tienen un cuarto atributo que hace referencia a su estado como son las
tareas. Estos cuatro atributos deben ser mostrados con claridad en la interfaz
del widget para permitir al usuario estar en todo momento al tanto del estado
de su máquina. El atributo power state tiene tres estados posibles: RUNNING,
SHUTDOWN y NOSTATE. El estado de la máquina virtual puede adoptar has-
ta diez valores distintos, entre ellos ACTIVE, STOPPED o SUSPENDED. Por
último, el estado principal de la instancia puede adoptar 17 valores distintos
entre los que se encuentran ACTIVE, PAUSED o REBOOT.
ImplementaciónDebido a la gran cantidad de estados posibles la implementación de esta fun-
cionalidad ha sido bastante más compleja de la llevada a cabo para los estados
de los otros widgets. Se ha decidido que se muestre en barra superior un solo
icono que englobe tres de los cuatro tipos de estados posibles de la instancia.
El icono consistirá, como en los otros widgets, de un símbolo enmarcado en
un pequeño recuadro de un color. Así, el icono indica en primera instancia
el estado de la instancia en función del símbolo elegido y el power state en
54
CAPÍTULO 3. DESARROLLO
función del color del recuadro tal y como se muestra en la Figura 3.11.
Figura 3.11: Estado de error
El estado de la máquina virtual se muestra mediante un tooltip, que no es más
que un pequeño recuadro de texto que aparece al pasar el ratón por encima
de un elemento en una página web. Este tooltip no solo muestra el estado
de la máquina virtual, sino que además incluye los otros dos tipos de estado
mencionados anteriormente como se muestra en la figura.
Figura 3.12: Tooltip mostrando los tres estados de una instancia
Por último, la tarea que se esté realizando se mostrará junto a los demás atri-
butos de la instancia en la parte central del widget. En el caso de que no se
esté llevando a cabo ninguna tarea se muestra el estado None, y en el caso en
que la instancia esté realizando alguna tarea se dibuja el nombre de la mis-
ma dentro de una barra de progreso animada que tiene un color determinado
dependiendo de la tarea en marcha.
Figura 3.13: Barra de tareas durante el despliegue
6. Editar los atributos de una instancia
55
CAPÍTULO 3. DESARROLLO
ObjetivoEl usuario debe ser capaz de editar los atributos de sus instancias para subsanar
cualquier error al introducir los datos durante su creación o por cualquier otra
razón. Esta edición debe ser sencilla para el usuario y además debe incluir
tantos atributos como sea posible modificar de acuerdo con el servicio Nova
de OpenStack.
ImplementaciónSe ha incluido un botón de edición de imagen en el desplegable .Actions" de la
barra superior del widget. Este botón despliega un formulario de edición en el
que se muestran todos los parámetros de la instancia que se pueden editar.
Casos de uso
Escenario 1 Recibir la ID de una instancia a través del sistema de conexiones de WireCloud
Dado un widget de detalles de instancia que no ha recibido una ID aún
Cuando recibe una ID de instancia
Entonces llama a la API del servicio Nova de OpenStack para obtener los datos de
la instancia correspondiente a la ID recibida
Escenario 2 Obtener y dibujar los parámetros de la instancia
Dado un widget de detalles de instancia que ha recibido una ID de instancia
Cuando se hace la llamada a la API de Nova
Entonces se obtienen los datos de la instancia y se pintan en la interfaz del widget
Escenario 3 Actualizar los datos del widget
Dado un widget de detalles de instancia mostrando los parámetros de una instancia
Cuando pasan cuatro segundos desde la última vez que se recibió una actualiza-
ción de los datos de la instancia
Entonces se envía otra petición para obtener los datos de la instancia
Escenario 4 Actualizar los datos del widget mostrando una instancia con un estado dis-
tinto de ACTIVE o que esté realizando una tarea
Dado un widget de detalles de instancia mostrando los atributos de una instancia
con estado distinto de ACTIVE
56
CAPÍTULO 3. DESARROLLO
Ó está realizando una tarea
Cuando pasa un segundo desde la última vez que se recibió una actualización de
los datos de la instancia
Entonces se envía otra petición para obtener los datos de la instancia
Escenario 5 Borrar una instancia
Dado un widget de detalles que está mostrando los atributos de una instancia
Cuando el usuario haga click en el botón de borrar instancia
Entonces el widget enviará una petición a la API de Nova para borrar la instancia
Y dejará de mostrar la instancia en la interfaz para volver a la vista por defecto a
la espera de una nueva instancia
Escenario 6 Reiniciar una instancia
Dado un widget de detalles que está mostrando los atributos de una instancia que
no está realizando ninguna tarea
Cuando el usuario haga click en el botón de reiniciar instancias
Entonces se iniciará el proceso de reinicio de la instancia
Escenario 7 Cambiar un atributo de una instancia
Dado una instancia mostrada en el widget de detalles
Cuando el usuario modifique uno o más atributos en el formulario de edición de
la instancia
Entonces el widget debe enviar una petición a la API de Nova para modificar los
atributos cambiados
Escenario 8 Mostrar los errores devueltos en la interfaz
Dado una petición a la API de OpenStack por parte del widget
Cuando se produce un error y el servidor de OpenStack te devuelve un mensaje de
error
Entonces el widget debe mostrar el error correctamente haciendo uso del sistema
de errores
57
CAPÍTULO 3. DESARROLLO
3.4 Componente de gestión de volúmenes
Este componente, al igual que los previamente descritos, está conformado por dos
widgets. El primero permite al usuario visualizar sus volúmenes y algunos de sus atributos
y el segundo, mostrar dichos atributos de una manera mucho más detallada.
Estas, sin embargo, no son las únicas funcionalidades que se han desarrollado para es-
tos widgets. En los siguientes apartados se dará cuenta detalladamente de las funcionali-
dades implementadas para los widgets de este componente que no hayan sido ya incluidas
en el pertinente apartado de librerías comunes.
3.4.1 Widget de listado de volúmenes
El widget de listado de volúmenes tiene el propósito de mostrar al usuario de una
manera organizada todos sus volúmenes a la vez que le permite otras funcionalidades
adicionales.
En este apartado se tratarán detalladamente las funcionalidades desarrolladas para este
widget que no estuvieran ya incluidas en el apartado de librería común de widgets de
listado, así como los casos de uso que se han utilizado como base para realizar las pruebas
unitarias.
Funcionalidades desarrolladas
Está sección esta dedicada a describir cada una de las funcionalidades desarrolladas
exclusivamente para este widget. Se hablará de los objetivos de cada una de ellas así
como de algunos detalles de su implementación.
1. Crear una lista de los volúmenes disponibles y pintarlos en la tabla
ObjetivoEsta es la funcionalidad principal del widget. Se debe obtener un listado de
todos los volúmenes creados por el usuario y a continuación dibujarlos en una
tabla en la que cada fila será un volumen y cada columna uno de sus atributos.
ImplementaciónLos volúmenes en OpenStack se gestionan a través del servicio Cinder en
OpenStack que es, por tanto, el que se utiliza para listar los volúmenes per-
tenecientes a un determinado usuario. Para realizar las llamadas a la API del
58
CAPÍTULO 3. DESARROLLO
servicio Cinder, se ha utilizado la librería JStack que ofrece una interfaz para
realizar llamadas Ajax a los distintos servicios de OpenStack. Como resultado
de esta llamada se obtiene un objeto con estructura JSON que contiene la lista
de volúmenes. Utilizando este objeto JSON se dibujan las instancias recibidas
en la tabla del widget, de manera que cada fila es un volumen y cada columna
es un atributo de dicho volumen.
2. Crear un volumen
ObjetivoEl usuario debe poder crear nuevos volúmenes pudiendo elegir las caracte-
rísticas de estos que crea convenientes. Se debe permitir al usuario elegir un
nombre, una descripción y un tamaño en GB para su nuevo volumen. Un vo-
lumen permite añadir espacio extra al seleccionado al crear una instancia. Por
tanto, esta es una funcionalidad muy importante en el conjunto del dashboard.
ImplementaciónLos usuario pueden crear nuevos volumenes a través del botón con el símbo-
lo más (+) que ha sido añadido en la barra inferior del widget. Este botón da
acceso al usuario a un formulario de creación de volúmenes, que le permite
introducir los datos necesarios para la creación de su nuevo volumen. Dichos
datos con el nombre del volumen, una descripción de tamaño limitado en la
que el usuario puede especificar la finalidad del volumen a modo de recorda-
torio y el tamaño en GB que se va a asignar al nuevo volumen al ser creado en
el servidor.
La petición de creación de un nuevo volumen se realiza también a través de
la librería JStack que hace una llamada AJAX a la API del servicio Cinder
de OpenStack. En el lado servidor, Cinder se ocupa de la creación del nuevo
volumen asignándole el espacio indicado.
En la Figura 3.14 se puede ver el formulario para la creación de un volumen.
3. Enviar la ID de un volumen a través de una conexión WireCloud al hacer click sobre
él
ObjetivoSe debe asegurar que cuando el usuario haga click en un volumen de la tabla se
envíe un evento a los widgets conectados a este a través de las conexiones de
WireCloud. En este caso el evento debe consistir en enviar la id del volumen
seleccionado a todos los widgets conectados a este.
59
CAPÍTULO 3. DESARROLLO
Figura 3.14: Formulario de creación de un volumen
ImplementaciónSe utiliza la API de WireCloud para enviar un evento que contenga la id del
volumen seleccionado a los demás widgets conectados.
Casos de uso
Escenario 1 Obtención de la lista de volúmenes
Dado un usuario que tiene volúmenes creados en una instancia de OpenStack
Cuando el widget hace la llamada de obtención de volúmenes
Entonces recibe una cadena de texto en formato JSON que incluya todos los volú-
menes del usuario
Escenario 2 Dibujar los volúmenes en la tabla
Dado un widget que ha pedido todos las volúmenes pertenecientes a un usuario de
OpenStack
Cuando reciba las instancias correctamente en forma de cadena de texto JSON
Entonces dibuja en la tabla del widget los volúmenes recibidos y los atributos de
este que hayan sido elegidos por el usuario en las preferencias del widget
Escenario 3 Actualizar el contenido de la tabla automáticamente
Dado un widget que ha recibido una lista de volúmenes
60
CAPÍTULO 3. DESARROLLO
Cuando pasan cuatro segundos
Entonces se realiza otra petición de obtención de volúmenes
Escenario 4 Mostrar las columnas elegidas en las preferencias
Dado un widget que está mostrando una lista de volúmenes en la tabla
Cuando el usuario cambia las preferencias seleccionando mostrar otros atributos
de los volúmenes
Entonces la tabla debe mostrar los atributos seleccionados por el usuario como
columnas de dicha tabla
Escenario 5 Crear un volumen
Dado un usuario que necesita crear un volumen
Cuando el usuario rellena y envía el formulario de creación de un volumen
Entonces el widget envía la petición POST al servicio Cinder de OpenStack y en el
lado servidor se crea el nuevo volumen con el tamaño, nombre y descripción
especificados por el usuario
Escenario 7 Mostrar los errores en la interfaz del widget
Dado un widget que hace una petición a un servicio de OpenStack
Cuando el servicio devuelve un error
Entonces el widget muestra el error en la interfaz gráfica en forma de mensaje de
alerta
Escenario 8 Mostrar en la tabla los volúmenes que coincidan con la búsqueda
Dado un usuario que quiere encontrar un volumen concreto en una tabla
Cuando el usuario introduce su criterio de búsqueda en el campo apropiado de la
barra inferior
Entonces la tabla sólo muestra los volúmenes que coinciden con el criterio de bús-
queda introducido por el usuario
Escenario 9 Enviar la ID de un volumen seleccionado a través del endpoint de salida
correspondiente
Dado un widget que muestra una tabla con los volúmenes de un usuario
Cuando el usuario hace click con el ratón sobre un volumen de la tabla
61
CAPÍTULO 3. DESARROLLO
Entonces el widget envía un evento por el endpoint de salida apropiado que con-
tiene la ID del volumen seleccionado
3.4.2 Widget de detalles de volumen
El widget de detalles de un volumen tiene por función proporcionar al usuario una in-
terfaz sencilla a través de la cual pueda acceder a toda la información relacionada con el
volumen que haya seleccionado en el widget de listado de volúmenes anteriormente des-
crito. Además, con este widget el usuario será capaz de manejar el proceso de asignación
de un volumen a una instancia y también el proceso contrario de liberacion de un volumen
que estaba asignado a una instancia.
Un volumen proporciona a la instancia a la que está asignado espacio de disco extra
como si de un disco duro externo se tratara. Gracias a este recurso el usuario puede ampliar
el espacio disponible en sus máquinas virtuales tanto como se lo permitan los recursos que
su cuenta tenga disponible.
En este apartado se van a describir detalladamente las funcionalidades implementadas
para este widget exclusivamente. Aquellas funcionalidades que el widget tenga en común
con otros ya han sido descritas en el pertinente apartado de librerías comunes de widgets.
Funcionalidades desarrolladas
En esta sección se llevará a cabo la explicación de los objetivos así como del proceso
de implementación de todas las funcionalidades desarrolladas para este widget de detalles
de un volumen.
1. Recibir ID de un volumen
ObjetivoEl widget debe poder recibir correctamente la ID del volumen que va a mostrar
en su interfaz a través del sistema de conexiones integrado en la plataforma
WireCloud. El widget debe indiferente a la procedencia del evento recibido.
ImplementaciónLa interfaz del widget muestra una vista por defecto siempre que no haya re-
cibido una ID del sistema de conexiones. La API de la plataforma WireCloud
permite definir un callback para el caso en que llegue un nuevo evento a tra-
vés del sistema de conexiones. De esta manera, el widget puede realizar las
62
CAPÍTULO 3. DESARROLLO
acciones adecuadas ante la recepción de un nuevo ID sin intervención alguna
por parte del usuario.
2. Obtener y dibujar los detalles de un volumen en la interfaz del widget
ObjetivoCuando llega un nuevo evento a través del sistema de conexiones conteniendo
un ID de volumen, el widget debe usar este nuevo ID para obtener del servi-
dor OpenStack todos los detalles de dicho volumen y pintarlos en la tabla de
manera adecuada.
ImplementaciónCuando se dispara el callback de recepción de un nuevo evento del sistema de
conexiones definido en Fun1, el widget realiza una llamada a la API del servi-
cio Cinder de OpenStack a través de la librería JStack para obtener todos los
atributos de un volumen. A la llamada a librería JStack se le pasa como argu-
mento un callback que se llamara cuando se reciba la respuesta del servidor.
Si la respuesta del servidor es correcta se procederá a dibujar en la interfaz
todos lo atributos recibidos en dicha llamada. La Figura 3.15 muestra la vista
principal del widget de detalles de volumen.
Figura 3.15: Widget de detalles de volumen
3. Borrar un volumen
ObjetivoPermitir al usuario borrar sus volúmenes. De esta manera el usuario puede
deshacerse de volúmenes creados defectuosamente, con parámetros incorrec-
63
CAPÍTULO 3. DESARROLLO
tos introducidos accidentalmente por el usuario durante su creación o simple-
mente que ya no sean útiles al usuario.
ImplementaciónSe ha añadido al desplegable .Actions" en la barra superior del widget un botón
de borrar volumen. Este botón tiene asignado un callback que se dispara con el
evento click. Este callback envía una petición a la API del servicio Cinder de
OpenStack a través de la librería JStack para borrar el volumen. Al realizar la
llamada a la librería JStack para borrar una imagen, se asigna un callback que
se dispara al recibir la respuesta de que la imagen se ha borrado correctamente
y dicho callback borra los datos de la imagen de la interfaz y vuelve a dibujar
la vista por defecto a la espera de la llegada de un nuevo ID de volumen a
través del sistema de conexiones de la plataforma WireCloud.
Cabe destacar que el usuario solo encontrará habilitado el botón de borrar
un volumen si el volumen se encuentra en un estado que permita esta acción
como por ejemplo AVAILABLE.
4. Asignar un volumen a una instancia
ObjetivoPermitir a un usuario asignar un volumen a una de sus instancias. Añadir vo-
lúmenes a una instancia es la mejor manera que tiene un usuario de conseguir
espacio extra para una de sus instancias. Además, se debe permitir al usua-
rio el punto de montaje que el volumen tendrá en la instancia seleccionada y
asegurarse de que este no coincida con otros volúmenes asignados a la misma
instancia. Un volumen solo puede asignarse a una instancia si está en estado
AVAILABLE.
ImplementaciónPara la implementación de esta funcionalidad se ha añadido al desplegable
.Actions" de la barra superior del widget un botón llamado “Attach volume”.
Este botón tiene asignado un callback que se dispara en el momento que se
hace click sobre él. Este callback abre un formulario para elegir los datos ne-
cesarios para adjuntar el volumen a una instancia. Estos datos son: la instancia
a la que se asigna el volumen y el punto de montaje del volumen en esa ins-
tancia.
Al hacer click en el botón de “Attach” del formulario, se realiza una llamada
a la API del servicio Nova que es el que gestiona las instancias en OpenStack
64
CAPÍTULO 3. DESARROLLO
en la que le indica el volumen, la instancia y el punto de montaje y OpenStack
se encarga de hacer la asignación y montar el volumen automáticamente en el
punto especificado por el usuario en el formulario de asignación de volumen.
Una vez se ha realizado la asignación en el servidor, el widget muestra la
instancia a la que está asignado el volumen. Un detalle a destacar es que el
usuario solo tendrá disponible el botón de asignar un volumen a una instancia
si el volumen se encuentra en estado AVAILABLE para evitar que la asigna-
ción interfiera con cualquier otra acción que pudiera estar llevando a cabo el
volumen.
5. Liberar un volumen de una instancia
ObjetivoPermitir a un usuario liberar un volumen de la instancia a la que está asignado.
Con esta funcionalidad se pretende que el usuario sea capaz de cambiar la
instancia a la que está asignado un volumen para poder mover datos de unas
instancias a otras o simplemente liberarlo a la espera de la creación de una
nueva instancia más apropiada para él.
ImplementaciónCuando un volumen está asignado a una instancia en la interrfaz del widget se
muestra la instancia a la que está asignado acompañada de una botón llamado
“detach” que el usuario puede usar para liberar el volumen de la instancia.
Cuando el usuario hace click en este botón se dispara un callback que llama
a la API del servicio Nova para que desmonte el volumen del la máquina
virtual en el punto de montaje que se le había asignado. Al llamar a la API
de Nova a través de la librería JStack se asigna un callback que se disparará
cuando el servidor confirme que el volumen ha sido liberado de la instancia.
Cuando este callback se dispara el widget pinta la actualización en su interfaz
de manera que vuelve a permitir al usuario asignar este volumen a cualquier
otra instancia.
El usuario solo podrá usar el botón de “detach” cuando el volumen esté asig-
nado a alguna instancia ya que de lo contrario este botón ni siquiera aparecerá
en la interfaz del widget. En la Figura 3.16 se ve el aspecto del widget de
detalles cuando el volumen mostrado está adjunto a una instancia.
6. Mostrar el estado del volumen en la interfaz
Objetivo
65
CAPÍTULO 3. DESARROLLO
Figura 3.16: Widget de detalles mostrando un volumen adjunto a una instancia
Permitir al usuario estar en todo momento consciente del estado de su volumen
para que así pueda saber cuándo puede asignárselo a una instancia, cuándo
puede liberarlo de una instancia, o cuándo puede borrarlo. El estado de un
volumen de OpenStack indica tanto el estado en el que se encuentra como si
está realizando alguna tarea. Los volúmenes pueden tener 11 estados distintos
entre los que se encuentran AVAILABLE, CREATING, IN-USE y ERROR.
ImplementaciónPara la implementación de esta funcionalidad se ha elegido, como en widgetsanteriores utilizar un código de símbolos y colores para significar los estados
posibles en que puede estar el volumen mostrado.
El estado del widget se muestra en la barra superior del widget junto al des-
plegable .Actions" y muestra uno de los 11 posibles estados del volumen. Esta
información es de vital importancia para el usuario ya que le permite saber que
acciones puede o no llevar a cabo en cada momento dependiendo del estado
mostrado. Por ejemplo, la Figura 3.17 muestra cómo el volumen deshabilita
las funciones de adjuntar y borrar cuando el widget se encuentra en estado
IN-USE.
7. Editar los atributos de un volumen
ObjetivoDar al usuario la capacidad de modificar los atributos que considere necesario
del volumen que está siendo visualizado por el widget. Los atributos que pue-
den ser modificados por esta funcionalidad son el nombre y la descripción del
66
CAPÍTULO 3. DESARROLLO
Figura 3.17: Estado del volumen deshabilita funciones de adjuntar y borrar
volumen en cuestión.
Esta funcionalidad permite al usuario reparar errores en los parámetros intro-
ducidos al crear el volumen sin necesidad de destruir el volumen y crearlo de
nuevo con la posible pérdida de datos que eso supondría.
ImplementaciónSe ha añadido un botón de edición de volumen al que el usuario puede acceder
a través del desplegable .Actions" en la barra superior del widget. Este botón
tiene asignado un callback que se dispara cuando se realiza un click sobre él.
Dicho callback realiza una llamada a la API del servicio Cinder de OpenStack
para que modifique los atributos que el usuario haya indicado en el formulario
de edición de volúmenes.
Casos de uso
Escenario 1 Recibir la ID de un volumen a través del sistema de conexiones de WireCloud
Dado un widget de detalles de volumen que no ha recibido una ID aún
Cuando recibe una ID de volumen
Entonces llama a la API del servicio Cinder de OpenStack para obtener los datos
de la instancia correspondiente a la ID recibida
Escenario 2 Obtener y dibujar los atributos del volumen
Dado un widget de detalles de volumen que ha recibido un ID a través del sistema
de conexiones
Cuando se hace la llamada a la API de Cinder
Entonces se obtienen los datos del volumen y se pintan en la interfaz del widget
67
CAPÍTULO 3. DESARROLLO
Escenario 3 Actualizar los datos del widget
Dado un widget de detalles mostrando los atributos de un volumen
Cuando pasan cuatro segundos desde la última vez que se recibió una actualiza-
ción de los datos del volumen
Entonces se envía otra petición para obtener los datos del volumen
Escenario 4 Actualizar los datos del widget mostrando un volumen con un estado distin-
to de AVAILABLE o IN-USE
Dado un widget de detalles de volumen mostrando los atributos de un volumen con
estado distinto de AVAILABLE
Ó un estado distinto de IN-USE
Cuando pasa un segundo desde la última vez que se recibió una actualización de
los datos del volumen
Entonces se envía otra petición para obtener los datos del volumen
Escenario 5 Borrar un volumen
Dado un widget de detalles que está mostrando los atributos de un volumen
Cuando el usuario haga click en el botón de borrar volumen
Entonces el widget enviará una petición a la API de Cinder para borrar el volumen
Y dejará de mostrar el volumen en la interfaz para volver a la vista por defecto a
la espera de un nuevo volumen
Escenario 6 Adjuntar un volumen a una instancia
Dado un widget de detalles mostrando los atributos de un volumen
Cuando el usuario hace click sobre el botón de adjuntar volumen
Y rellena y envía el formulario para adjuntar un volumen a una instancia
Entonces el widget realiza una llamada a la API de Cinder para adjuntar el volu-
men a la instancia elegida
Escenario 7 Liberar un volumen de una instancia
Dado un widget de detalles mostrando los atributos de un volumen
68
CAPÍTULO 3. DESARROLLO
Cuando el usuario hace click sobre el botón de liberar volumen asignado a una
instancia
Entonces el widget realiza una llamada a la API de Cinder para liberar el volumen
de la instancia a la que está asignado
Escenario 8 Cambiar un atributo de un volumen
Dado un volumen mostrado en el widget de detalles
Cuando el usuario modifique uno o más atributos en el formulario de edición del
volumen
Entonces el widget debe enviar una petición a la API de Cinder para modificar los
atributos cambiados
Escenario 9 Mostrar los errores devueltos en la interfaz
Dado una petición a la API de OpenStack por parte del widget
Cuando se produce un error y el servidor de OpenStack te devuelve un mensaje de
error
Entonces el widget debe mostrar el error correctamente haciendo uso del sistema
de errores
3.5 Flujo del proceso de autenticación contra Keystone
En este apartado se explicará el proceso llevado a cabo para autorizar y autenticar a un
usuario en el servicio Keystone. El servicio Keystone de OpenStack es el que controla el
acceso de los usuarios a los demás servicios de OpenStack además de proveer un catálogo
con todos los servicios disponibles. Para acceder a él se usa un proxy por cada región de
FIWARE que da acceso a la única instancia existente. En cualquier caso el proceso de
autenticación es igual que si se realizara sobre una única instalación de OpenStack.
El primer paso del proceso requiere que el usuario envíe a Keystone sus credenciales
(usuario y contraseña) o un token aceptado esa instalación de OpenStack. En el ámbito
de este Trabajo de Fin de Grado se ha utilizado la aplicación de Cloud de FI-WARE Lab
que tiene su propio sistema de autenticación integrado llamado IDM (Identity Manager)
que provee un token de OAuth2. Este token sirve para hacer la petición inicial del proceso
de autenticación. Como WireCloud está también utiliza el IDM se puede obtener el token
69
CAPÍTULO 3. DESARROLLO
OAuth2 realizando la petición a través del proxy de WireCloud y pidiéndole que incluya
el dicho token en el cuarpo del mensaje.
De la petición anterior utilizando el token de OAuth2 del IDM, se obtiene el tenant(o project en Keystone v3) del usuario, que será necesario para acceder a la mayoría de
los servicios de OpenStack así como el token de servicios de Keystone que permitirá
al usuario acceder a todos los demás servicios de OpenStack y un catálogo listando los
servicios disponibles en cada región.
Este proceso de autenticación tiene normalmente algunos pasos más debido al uso
de credenciales de usuario en lugar de un token OAuth2 aceptado por la instancia de
OpenStack. En la Figura 3.18 puede verse el proceso completo de autenticación en Keys-
tone.
Figura 3.18: Flujo del proceso de autenticación en Keystone
3.6 Autenticación integrada en la plataforma WireCloud
En este apartado se explicará cómo se ha integrado el proceso de autenticación expli-
cado anteriormente en la plataforma WireCloud y los objetivos de esta mejora.
70
CAPÍTULO 3. DESARROLLO
La obtención de credenciales de OpenStack debería ser totalmente transparente a los
widgets ya que no es un proceso en el que el usuario tenga por qué participar ni del que
tenga por qué ser consciente. El objetivo, por tanto, de la integración en la plataforma
Wirecloud de la autenticación contra el servicio Keystone de OpenStack es conseguir que
el proceso de obtención de credenciales de OpenStack sea completamente invisible al
usuario.
Para conseguir este objetivo se ha sacado provecho de la gran capacidad de modula-
rización de la plataforma WireCloud para integrar una librería en su lado cliente, que se
encarga de realizar el proceso de autenticación. La librería espera a que uno de los widgetsdel dashboard le haga una petición de autenticación para iniciar el proceso y, de manera
asíncrona se le devolverá un token que el widget podrá utilizar para acceder a los servi-
cios de OpenStack como se indica en la Figura 3.18. A todos los widgets que soliciten la
autenticación contra Keystone después de que la primera haya sido resuelta se les propor-
cionará este token de manera síncrona ya que la librería de autenticación integrada ya lo
tiene en lado cliente.
De esta manera se consigue evitar que un dashboard tenga que autenticarse varias
veces (una por cada widget) para poder funcionar, lo cual no tenía sentido al tener ya
una plataforma común que podría manejar este proceso por ellos y hacerlo, por tanto,
transparente al usuario.
3.7 Dificultades encontradas en el desarrollo
Durante el desarrollo llevado a cabo durante el presente Trabajo de Fin de Grado se han
encontrado muchos problemas relacionados tanto con el carácter experimental de muchas
de las plataformas utilizadas como con fallos en las plataformas y servicios de terceros
que han condicionado el desarrollo. A lo largo de este apartado se dará cuenta de dichos
problemas de manera resumida.
En primer lugar, el servicio de Cloud desarrollado por otros socios dentro del proyecto
FIWARE ha generado algunos problemas debidos a la baja disponibilidad de sus servicios
al tratarse de un Cloud experimental dedicado al desarrollo. En algunos casos el desarrollo
de las pruebas se ha visto perturbado por el incorrecto funcionamiento de algunos de los
servicios de este cloud.
Por otro lado, el despliegue de una nueva versión del IdM ha introducido más inestabi-
lidad y ha durado más de lo deseable, viéndose afectado el acceso al servicio. Su funcio-
71
CAPÍTULO 3. DESARROLLO
namiento en los primeros días no ha estado exento de errores, por lo que el desarrollo y
pruebas de otros componentes se ha visto comprometido al depender de la autenticación
y autorización frente al propio IdM.
En cualquier caso estos problemas son fruto del carácter experimental de las herra-
mientas que se han utilizado y los retrasos ocasionados por ellos no han tenido ningun
impacto en el resultado final del trabajo ya que, gracias al esfuerzo extra realizado, se
han cumplido los requisitos iniciales del trabajo y se ha conseguido desarrollar el soporte
para múltiples regiones, que no estaba entre los objetivos iniciales del Trabajo de Fin de
Grado.
72
Capítulo 4
RESULTADOS Y CONCLUSIONES
En este Trabajo de Fin de Grado, se ha desarrollado un conjunto de widgets componi-
bles que actúan como dashboard fácilmente configurable de una instalación de OpenStack,
que además implementa nuevas funcionalidades no incluidas en otras soluciones como el
servicio Horizon de OpenStack.
El desarrollo ha incluido las fases de análisis de proyectos previos, diseño de la estruc-
tura del proyecto y de cada uno de los widgets, implementación de los diseños anteriores,
diseño de pruebas unitarias para cada uno de los widgets y refactorización final del códi-
go.
Estas fases han sido llevadas a cabo de manera simultánea ya que los distintos compo-
nentes fueron empezando a desarrollarse de manera escalonada.
En los siguientes apartados se recogen las conclusiones, tanto a nivel de resultados
como a nivel personal que se han podido obtener de este Trabajo de Fin de Grado, así
como las líneas futuras de desarrollo del proyecto FI-Dash, en el que se engloba este
Trabajo de Fin de Grado.
4.1 Resultados
Tanto el proyecto OpenStack como la plataforma WireCloud están en continuo desa-
rrollo y se mantienen actualizados con las tecnologías más actuales, así que durante los
estudios previos realizados como parte del presente Trabajo de Fin de Grado se han tenido
en cuenta las últimas tecnologías utilizadas en el desarrollo de aplicaciones web como el
automatizador de tareas Grunt, o los frameworks de desarrollo de tests Jasmine y Karma.
73
CAPÍTULO 4. RESULTADOS Y CONCLUSIONES
Durante la fase de diseño de los componentes, se han tomado varias decisiones impor-
tantes de cara a facilitar el desarrollo, como la creación de una librería que contiene todo el
código común a todos los widgets, por ejemplo los estilos CSS o algunas funcionalidades
de utilidad como los campos de búsqueda de las tablas.
La fase de implementación ha sido la que más tiempo ha consumido. Durante esta
fase se ha conseguido construir los distintos componentes que conforman el dashboardconfigurable y componible que permite al usuario gestionar una instancia de OpenStack,
a través del desarrollo de los widgets que forman parte de cada componente y que ya han
sido descritos en profundidad en el capítulo anterior.
También se ha añadido una funcionalidad que en un principio no estaba planificada
para este Trabajo de Fin de Grado como es el soporte en el dashboard para la gestión de
múltiples regiones.
En la fase de pruebas se ha utilizado la librería Jasmine, a través del framework Karma,
para el diseño y ejecución de las pruebas unitarias diseñadas a partir de los distintos ca-
sos de uso. Karma permite realizar los tests en distintos navegadores, lo que ha facilitado
encontrar varios problemas de compatibilidad y ha permitido que todos los componen-
tes realizados puedan ser ejecutados en los navegadores más usados con garantías de su
correcto funcionamiento.
Por último, se ha llevado a cabo una fase de refactorización del código del proyecto
con el objetivo de hacer el código más reusable y sobretodo legible para aquellos que
continúen el proyecto FI-Dash.
4.2 Conclusiones personales
La realización de este Trabajo de Fin de Grado me ha permitido participar de la expe-
riencia de trabajar en un entorno profesional lleno de gente dispuesta a ayudarme a dar
mis primeros pasos en el mundo laboral como es el laboratorio CoNWeT del grupo de
investigación CETTICO, en la Escuela Técnica Superior de Ingenieros Informáticos.
Durante mi estancia en dicho laboratorio he aprendido muchas tecnologías, herramien-
tas y metodologías de trabajo que sin duda me ayudarán a formar un currículum muy com-
pleto con el que entrar en el mundo laboral. Entre los conocimientos adquiridos durante
la realización del Trabajo de Fin de Grado se cuentan lenguajes de programación como
JavaScript (tanto lado cliente como servidor) y Python (aunque lo he utilizado en menor
74
CAPÍTULO 4. RESULTADOS Y CONCLUSIONES
medida), frameworks de testing como Jasmine y Karma, y herramientas muy importantes
y utilizadas como Grunt, NPM o Git.
Pero no solo he adquirido conocimientos sobre herramientas y tecnologías sino que
también he podido profundizar en conceptos como Test Driven Development (TDD), bue-
nas prácticas de programación bajo diversos paradigmas y metodologías de desarrollo de
software.
En lo que se refiere a mis aptitudes personales, he tenido la oportunidad aprender cómo
trabajan grandes equipos de distintos países en el desarrollo de proyectos como FIWARE
así como coger el ritmo de trabajo de un proyecto profesional. Sin duda alguna estos
conocimientos son extremadamente útiles en el mundo empresarial y supondrán un salto
cualitativo en mi rendimiento profesional en los apartados de la organización del tiempo,
las prioridades y el trabajo bajo la presión de fechas límite.
Por último, debo destacar el buen ambiente que he vivido en el entorno de trabajo.
Siempre hubo gente dispuesta a ayudarme con las dudas técnicas o a solventar problemas
relacionados con la falta de documentación o funcionalidad de software de terceros que
nos hayamos visto obligados a usar en algún momento determinado. Siempre se puede
aprender algo de todo el mundo y aún más si están dispuestos a ayudarte como ha sido mi
caso, por ello he de agradecer a todos los componentes del laboratorio CoNWeT que me
han ayudado a lograr todos los objetivos planteados para este Trabajo de Fin de Grado.
4.3 Líneas futuras
A modo de conclusión, en este apartado se mencionan líneas futuras de desarrollo que
hay abiertas en el proyecto FI-Dash.
El objetivo más próximo es la comunicación de todas las modificaciones que se pro-
duzcan en cada widget hacia los demás a través del editor de conexiones de la plataforma
WireCloud. Esto aumentaría la velocidad con la que el usuario ve su información actua-
lizada en pantalla. Por supuesto, se utilizaría el sistema de friendcodes de la plataforma
para hacer que sólo los widgets interesados reciban cada mensaje de actualización. Esto,
por supuesto, tiene como inconveniente un sistema de conexiones increíblemente comple-
jo entre los widgets, que sería muy frustrante para el usuario que quisiera añadir un nuevo
elemento al dashboard.
Como solución, se ha pensado añadir a la plataforma WireCloud un sistema de wiringautomático que, permitirá que los endpoints de actualización de los widgets se conecten
75
CAPÍTULO 4. RESULTADOS Y CONCLUSIONES
con todos los demás con los que compartan friendcode según son añadidos al workspaceahorrándole al usuario la necesidad de hacer una ingente cantidad de conexiones cada
vez que desee añadir un widget al dashboard. Con esta nueva característica, sumada al
ya existente sistema de comportamientos del editor de conexiones de WireCloud, que
permite separar grupos de widgets y/o conexiones y mostrarlos en vistas separadas, se
permitirá al usuario editar las conexiones entre sus widgets sin ver su editor inundado con
un sinfín de conexiones.
Otra de las líneas de desarrollo interesantes de cara al futuro próximo es la monitori-
zación de los recursos de un usuario que le permita a éste conocer en todo momento el
uso que ha hecho de los recursos disponibles para su cuenta.
Sin duda estas dos posibles líneas de desarrollo prueban el acierto y la potencia de la
idea de desarrollar el proyecto FI-Dash en la plataforma WireCloud.
76
Apéndice A
MANUAL DE USUARIO
Este anexo pretende ser un guía para usuario que quieran usar el dashboard de OpenStack
desarrollado en el presente Trabajo de Fin de Grado. A lo largo del mismo se cubrirán los
pasos necesarios para el despliegue del dashboard en la plataforma WireCloud, así como
una guía sobre la ubicación en la interfaz gráfica de las distintas funcionalidades.
A.1 Despliegue del dashboard
El dashboard puede ser ofrecido al usuario de dos maneras: previemente preparado
por el proveedor en un mashup, o separado en sus distintos componentes en el catálogo
de widgets de la plataforma WireCloud. En cualquier caso se asume que los widgets o el
mashup ya están añadidos al catálogo de WireCloud.
En el caso que el usuario reciba el dashboard como mashup, existen dos opciones para
desplegarlo:
La primera es añadir el dashboard al workspace actual sin necesidad de crear uno
nuevo. Los pasos a realizar son los siguientes:
1. Pulsar en la pestaña Añadir widgets en la vista principal del workspace. Esto
desplegará un panel en el lado izquierdo de la pantalla conteniendo un listado
de los widgets y mashups disponibles.
77
APÉNDICE A. MANUAL DE USUARIO
Figura A.1: Hacer click en la pestaña de añadir widgets
2. Hacer click en el botón Mashups mostrará los mashups disponibles para el
usuario entre ellos el del dashboard.
Figura A.2: Panel de selección de widgets y mashups
3. Pulsar sobre el botón "Mezclarçon el símbolo ’+’ para añadir el dashboard al
workspace actual.
Figura A.3: Seleccionar el mashup del dashboard
La segunda opción es crear un nuevo workspace usando el mashup del dashboardcomo plantilla al crearlo. Se deben llevar a cabo los siguientes pasos:
1. Hacer click izquierdo sobre el botón de opciones de la vista principal del
78
APÉNDICE A. MANUAL DE USUARIO
workspace y seleccionar en el desplegable la opción "Nuevo entorno de traba-
jo".
Figura A.4: Seleccionar ’Nuevo entorno de trabajo’ en el desplegable
2. Esto abrirá un diálogo de creación de workspace en el que se deberá elegir un
nombre y a continuación pulsar en el botón de buscar plantilla.
Figura A.5: Diálogo de creación de workspace
3. Se abrirá un diálogo de selección de plantilla y se deberá elegir el mashup del
dashboard como plantilla.
79
APÉNDICE A. MANUAL DE USUARIO
Figura A.6: Diálogo de selección de plantilla
4. Esta acción devolverá al usuario al dialogo de creación de workspace donde se
debe hacer click en Aceptar para crear un nuevo workspace con el dashboardya desplegado en él.
A.2 Manual de widgets de tablas
En este apartado se cubren las funcionalidades incluidas en los widgets de tabla de una
manera genérica excepto en aquellos casos que difieran dependiendo del tipo de recurso
que tratan.
A.2.1 Creación de recursos
Esta sección explica paso a paso como crear un recurso desde la interfaz del widget.Dado que este proceso es diferente para cada tipo de recurso, se explicarán por separado
imágenes, instancias y volúmenes.
Imágenes
Los pasos a llevar a cabo para crear una nueva imagen son:
1. Pulsar sobre el botón azul con el icono + para desplegar el formulario de creación
de imágenes.
80
APÉNDICE A. MANUAL DE USUARIO
Figura A.7: Botón de crear recurso en azul
2. Una vez en el formulario se puede crear la imagen directamente ya que ningún cam-
po es obligatorio, pero esto generaría una imagen totalmente inútil. Se recomienda
añadir un nombre a la imagen para distinguirla de otras (aunque no tiene que ser
único).
Figura A.8: Formulario de creación de una imagen
3. Si se crea la imagen sin un archivo estará en estado QUEUED y no se podrá hacer
nada con ella a no ser que se indique el tamaño 0. Por lo tanto es recomendable
añadir un archivo de imagen ya sea local o proporcionando una URL. la Figura A.9
muestra los campos para elegir el archivo de imagen y su origen.
81
APÉNDICE A. MANUAL DE USUARIO
Figura A.9: Campos para elegir el origen del archivo
4. Si se ha elegido un archivo de imagen los campos de disk format y container for-mat se vuelven requeridos para crear la imagen. Se debe introducir en cada uno el
formato de la imagen y el del contenedor si lo tuviera. La Figura A.10 muestra los
campos para elegir los formatos del archivo de imagen.
Figura A.10: Campos para elegir los formatos de imagen y contenedor
5. Los parámetros de minRAM y minDisk son opcionales e indican la cantidad mínima
de RAM y espacio en disco que se requerirá en la instancia que use esta imagen.
Figura A.11: Campos para elegir los mínimos requeridos por la imagen
6. Indicar si se desea que la imagen sea pública y/o protegida y la región en la que se
quiere crear.
7. Una vez estén listos todos los parámetros se debe hacer click sobre el botón de crear
imagen.
82
APÉNDICE A. MANUAL DE USUARIO
Figura A.12: Campos para elegir protección visibilidad y region
Instancias
Los pasos a llevar a cabo para crear una nueva instancia son:
1. Pulsar sobre el botón azul con el icono + para desplegar el formulario de creación
de instancias.Este botón se puede ver en la Figura A.7.
2. Elegir un nombre para la instancia.
3. Elegir un archivo de clave SSH
Figura A.13: Campo para elegir el archivo de clave SSH
4. Elegir un flavor. Según el flavor elegido serán distintos los recursos que consumirá
la instancia.
Figura A.14: Campo para elegir el flavor con que se creará la instancia
5. Seleccionar la región en la que se quiere crear la instancia.
Figura A.15: Campo para elegir la región en que se creará la instancia
83
APÉNDICE A. MANUAL DE USUARIO
6. Seleccionar la imagen a partir de la que se va a desplegar la instancia. Todas las
imágenes están disponibles en un desplegable del formulario.
84
APÉNDICE A. MANUAL DE USUARIO
Figura A.16: Campo para elegir la imagen desde la que se lanzará ala nueva instancia
7. Elegir el grupo de seguridad, que es el que tiene las configuraciones sobre los puer-
tos de la instancia que permiten recibir conexiones.
Figura A.17: Campo para elegir el grupo de seguridad de la nueva instancia
8. Por último, se pulsa sobre el botón de crear instancia y la información se manda al
servidor donde se creará la nueva instancia.
Volúmenes
Los pasos a llevar a cabo para crear un nuevo volumen son:
1. Pulsar sobre el botón azul con el icono + para desplegar el formulario de creación
de volúmenes. Este botón se puede ver en la Figura A.7.
2. Los campos obligatorios son el nombre y el tamaño del volumen y la región en que
se creará. Adicionalmente se puede proporcionar una descripción. La Figura A.18
muestra el formulario de creación de un volumen.
3. Cuando se tengan listos los parámetros basta con pulsar sobre el botón de crear
volumen.
A.2.2 Selección de regiones
El dashboard desarrollado soporta la gestión de múltiples regiones de manera simul-
tanea. Para elegir las regiones que queremos manejar basta con hacer click sobre el botón
de selección de regiones para desplegar el selector. A continuación se eligen aquellas re-
giones que se quieran gestionar y el widget empezará a mostrar automáticamente recursos
de dichas regiones.
85
APÉNDICE A. MANUAL DE USUARIO
Figura A.18: Formulario de creación de un volumen
A.2.3 Utilidades de la tabla
En esta sección se explican aquellas funcionalidades que no están directamente rela-
cionadas con OpenStack en sí pero que aportan algún tipo de utilidad al widget para hacer
su manejo más sencillo por parte del usuario.
Búsqueda
Cuando una tabla está mostrando muchos recursos simultánemente, la funcionalidad
de búsqueda ayuda al usuario a encontrar el que está buscando precisamente.
Se puede acceder a la barra de búsqueda pulsando sobre el botón con el icono de
la lupa, acción que desplegara el campo de búsqueda. La razón para que el campo esté
escondido hasta que el usuario lo descubra pulsando el botón es el ahorro de espacio que
esto supone.
Una vez desplegado, cualquier caracter que el usuario escriba en el campo hará que en
la tabla solo se muestren los recursos que coincidan con lo escrito de manera automática.
Figura A.19: Campo de búsqueda
86
APÉNDICE A. MANUAL DE USUARIO
Paginación
La paginación es una funcionalidad increíblemente útil cuando se trata con tablas con
muchos elementos. De esta manera el usuario puede ver los elementos en selecciones
manejables. Los mandos de paginación se encuentran en la parte inferior derecha del
widget e incluyen funciones para ir a la página anterior, siguiente primera, última o una
en específico.
Figura A.20: Mandos de paginación
Selección de contenido de la tabla
El usuario puede elegir qué atributos de los recursos se mostrarán en la tabla. Para ello
basta con ir al menú del widget y seleccionar la opción Configurar.
Figura A.21: Menu de opciones del widget
A continuación, se eligen aquellos atributos que se quieran mostrar y la tabla cambiará
automáticamente.
87
APÉNDICE A. MANUAL DE USUARIO
Figura A.22: Menú de selección de campos
A.3 Manual de widgets de detalles
En este apartado se describe el acceso y uso de las funcionalidades de los widgets de
detalles de un recurso. Se tratarán estas funcionalidades de manera genérica para los tres
tipos de recurso excepto en casos en los que su comportamiento varíe de uno a otro.
A.3.1 Borrado de recursos
Todos los recursos manejados por los widgets de detalles pueden ser eliminados de la
misma manera. En el desplegable Actions existe la opción de borrar el recurso y basta con
pulsar sobre ella para que el widget solicite el borrado del recurso y vuelva a la vista por
defecto.
88
APÉNDICE A. MANUAL DE USUARIO
Figura A.23: Desplegable Actions donde se encuentra el botón de borrar
A.3.2 Edición de recursos
El proceso de edición es parecido en los tres tipos de recursos que se manejan salvo los
atributos a modificar que son propios de cada tipo de recurso. Por tanto, solo se explica la
edición de manera genérica.
Para editar un recurso basta con acudir al desplegable Actions y seleccionar la opción
de edición. En la Figura A.23 se puede ver la localización del botón de edición.
Esto mostrará el formulario de edición del recurso y el usuario podrá guardar sus ac-
tualizaciones pulsando el botón de guardar.
Figura A.24: Formulario de edición de una imagen
89
APÉNDICE A. MANUAL DE USUARIO
A.3.3 Estados
Los estados son una parte muy importante del manejo de los recursos de OpenStack, ya
que dicen al usuario qué acciones puede realizar en cada momento además de informarles
del resultado de acciones previas. En esta sección se incluyen algunos de los estados más
importantes de cada uno de los tres tipos de recurso.
No se incluyen en esta sección todos los estados posibles ya que son demasiados, pero
se recuerda al usuario que en caso de duda le basta con posicionar el puntar sobre el icono
de estado y un tooltip le informará del estado en que se encuentra el recurso.
Imágenes
Figura A.25: Estado ACTIVE Figura A.26: Estado QUEUED
Instancias
Figura A.27: Estado AC-
TIVE
Figura A.28: Estado
ERROR
Figura A.29: Estado
BUILD
90
APÉNDICE A. MANUAL DE USUARIO
Volúmenes
Figura A.30: Estado
AVAILABLE
Figura A.31: Estado IN-
USE
Figura A.32: Estado
CREATING
91
APÉNDICE A. MANUAL DE USUARIO
92
Bibliografía
[1] OpenStack, Página oficial del proyecto.
[2] FIWARE, Página oficial del proyecto.
[3] CoNWeT Lab, Página oficial del laboratorio.
[4] WireCloud, Página oficial del proyecto.
[5] Portal Cloud, Página del proyecto en el catálogo de FIWARE.
[6] Lenguaje JavaScript, Página en MDN.
[7] JavaScript Object Notation, Página oficial.
[8] Lenguaje HTML, Página de Wikipedia sobre HTML.
[9] Versión 5 de HTML, Especificación del W3C.
[10] Application Programming Interface, Página sobre API en Wikipedia.
[11] Representational State Transfer, Página de REST en Wikipedia.
[12] Cascade Style Sheet, Página de CSS en Wikipedia.
[13] Git, Página oficial de Git.
[14] Integración continua, Página de Wikipedia sobre Integración continua.
[15] Jenkins, Página oficial de Jenkins.
[16] Widget, Página de Wikipedia sobre Widgets.
[17] Mashup, Página de Wikipedia sobre Mashups.
[18] Node JS, Página oficial de NodeJS.
[19] JQuery, Página oficial de JQuery.
[20] ECMAScript, Página oficial de ECMAScript.
93
BIBLIOGRAFÍA
[21] Pruebas unitarias, Página de Wikipedia sobre pruebas unitarias.
[22] Jasmine, Página oficial del proyecto.
[23] Jasmine JQuery, Página en GitHub del proyecto.
[24] Istanbul, Página en GitHub del proyecto.
[25] Grunt, Página oficial del proyecto.
[26] Karma, Página oficial del proyecto.
94
Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,