Dashboard conﬁgurable para la gestión y...

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

OpenStack

Autor: Braulio Grana Gutiérrez

Director: Miguel Jiménez Gañán

MADRID, JUNIO 2015

Índice general

RESUMEN vii

1 INTRODUCCIÓN Y OBJETIVOS 11.1 Motivaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 ESTADO DEL ARTE 52.1 Tecnologías de computación en la nube . . . . . . . . . . . . . . . . . . 5

2.2 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Tipos de recurso en OpenStack . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.1 Imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3.2 Instancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.3 Volúmenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Tecnologías de desarrollo web . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1 HyperText Markup Language (HTML) . . . . . . . . . . . . . . 18

2.4.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.3 JavaScript Object Notation (JSON) . . . . . . . . . . . . . . . . 20

2.4.4 Cascading Style Sheet (CSS) . . . . . . . . . . . . . . . . . . . . 20

2.4.5 JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 FIWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5.1 Plataforma WireCloud . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.2 Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.6 Tipos de componentes web en WireCloud . . . . . . . . . . . . . . . . . 23

2.6.1 Widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6.2 Operador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.6.3 Mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.7 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.8 Pruebas unitarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

iii

2.8.1 Jasmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.8.2 Karma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.9 Integración continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.9.1 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.10 Grunt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3 DESARROLLO 313.1 Librerías de funcionalidades comunes a varios widgets . . . . . . . . . . 32

3.1.1 Librería de widgets de listado de recursos . . . . . . . . . . . . . 32

3.1.2 Librería de widgets de visualización detallada de un recurso . . . 37

3.2 Componente de gestión de imágenes . . . . . . . . . . . . . . . . . . . . 39

3.2.1 Widget de listado de imágenes . . . . . . . . . . . . . . . . . . . 39

3.2.2 Widget de detalles de imagen . . . . . . . . . . . . . . . . . . . 43

3.3 Componente de gestión de instancias . . . . . . . . . . . . . . . . . . . . 48

3.3.1 Widget de listado de instancias . . . . . . . . . . . . . . . . . . . 48

3.3.2 Widget de detalles de instancias . . . . . . . . . . . . . . . . . . 52

3.4 Componente de gestión de volúmenes . . . . . . . . . . . . . . . . . . . 58

3.4.1 Widget de listado de volúmenes . . . . . . . . . . . . . . . . . . 58

3.4.2 Widget de detalles de volumen . . . . . . . . . . . . . . . . . . . 62

3.5 Flujo del proceso de autenticación contra Keystone . . . . . . . . . . . . 69

3.6 Autenticación integrada en la plataforma WireCloud . . . . . . . . . . . 70

3.7 Dificultades encontradas en el desarrollo . . . . . . . . . . . . . . . . . . 71

4 RESULTADOS Y CONCLUSIONES 734.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.2 Conclusiones personales . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.3 Líneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

A MANUAL DE USUARIO 77A.1 Despliegue del dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.2 Manual de widgets de tablas . . . . . . . . . . . . . . . . . . . . . . . . 80

A.2.1 Creación de recursos . . . . . . . . . . . . . . . . . . . . . . . . 80

A.2.2 Selección de regiones . . . . . . . . . . . . . . . . . . . . . . . . 85

A.2.3 Utilidades de la tabla . . . . . . . . . . . . . . . . . . . . . . . . 86

A.3 Manual de widgets de detalles . . . . . . . . . . . . . . . . . . . . . . . 88

A.3.1 Borrado de recursos . . . . . . . . . . . . . . . . . . . . . . . . 88

A.3.2 Edición de recursos . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.3.3 Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

iv

Índice de figuras

2.1 Diagrama de la arquitectura OpenStack . . . . . . . . . . . . . . . . . . 9

2.2 Diagrama de transiciones entre estados de una imagen . . . . . . . . . . . 14

2.3 Creación de una instancia . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Diagrama de estados de una instancia . . . . . . . . . . . . . . . . . . . 16

2.5 Esquema del DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.6 Composición de un mashup en el editor de conexiones de WireCloud . . . 23

2.7 Ejemplos de widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.8 Arquitectura mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.9 Ejemplo de flujo de desarrollo en Git . . . . . . . . . . . . . . . . . . . . 26

3.1 Vista de un widget de tablas . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2 Funcionamiento de la búsqueda en la tabla . . . . . . . . . . . . . . . . . 35

3.3 Error mostrado en la tabla . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.4 Menú de selección de regiones . . . . . . . . . . . . . . . . . . . . . . . 37

3.5 Formulario de creación de una imagen . . . . . . . . . . . . . . . . . . . 40

3.6 Vista de detalles del widget . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.7 Estado AVAILABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.8 Formulario de edición de una imagen . . . . . . . . . . . . . . . . . . . 46

3.9 Formulario de creación de una instancia . . . . . . . . . . . . . . . . . . 50

3.10 Widget de detalles de instancia . . . . . . . . . . . . . . . . . . . . . . . 53

3.11 Estado de error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.12 Tooltip mostrando los tres estados de una instancia . . . . . . . . . . . . 55

3.13 Barra de tareas durante el despliegue . . . . . . . . . . . . . . . . . . . . 55

3.14 Formulario de creación de un volumen . . . . . . . . . . . . . . . . . . . 60

3.15 Widget de detalles de volumen . . . . . . . . . . . . . . . . . . . . . . . 63

3.16 Widget de detalles mostrando un volumen adjunto a una instancia . . . . 66

3.17 Estado del volumen deshabilita funciones de adjuntar y borrar . . . . . . 67

3.18 Flujo del proceso de autenticación en Keystone . . . . . . . . . . . . . . 70

v

A.1 Hacer click en la pestaña de añadir widgets . . . . . . . . . . . . . . . . 78

A.2 Panel de selección de widgets y mashups . . . . . . . . . . . . . . . . . . 78

A.3 Seleccionar el mashup del dashboard . . . . . . . . . . . . . . . . . . . . 78

A.4 Seleccionar ’Nuevo entorno de trabajo’ en el desplegable . . . . . . . . . 79

A.5 Diálogo de creación de workspace . . . . . . . . . . . . . . . . . . . . . 79

A.6 Diálogo de selección de plantilla . . . . . . . . . . . . . . . . . . . . . . 80

A.7 Botón de crear recurso en azul . . . . . . . . . . . . . . . . . . . . . . . 81

A.8 Formulario de creación de una imagen . . . . . . . . . . . . . . . . . . . 81

A.9 Campos para elegir el origen del archivo . . . . . . . . . . . . . . . . . . 82

A.10 Campos para elegir los formatos de imagen y contenedor . . . . . . . . . 82

A.11 Campos para elegir los mínimos requeridos por la imagen . . . . . . . . . 82

A.12 Campos para elegir protección visibilidad y region . . . . . . . . . . . . 83

A.13 Campo para elegir el archivo de clave SSH . . . . . . . . . . . . . . . . . 83

A.14 Campo para elegir el flavor con que se creará la instancia . . . . . . . . . 83

A.15 Campo para elegir la región en que se creará la instancia . . . . . . . . . 83

A.16 Campo para elegir la imagen desde la que se lanzará ala nueva instancia . 85

A.17 Campo para elegir el grupo de seguridad de la nueva instancia . . . . . . 85

A.18 Formulario de creación de un volumen . . . . . . . . . . . . . . . . . . . 86

A.19 Campo de búsqueda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A.20 Mandos de paginación . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

A.21 Menu de opciones del widget . . . . . . . . . . . . . . . . . . . . . . . . 87

A.22 Menú de selección de campos . . . . . . . . . . . . . . . . . . . . . . . 88

A.23 Desplegable Actions donde se encuentra el botón de borrar . . . . . . . . 89

A.24 Formulario de edición de una imagen . . . . . . . . . . . . . . . . . . . 89

A.25 Estado ACTIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.26 Estado QUEUED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.27 Estado ACTIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.28 Estado ERROR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.29 Estado BUILD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.30 Estado AVAILABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.31 Estado IN-USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.32 Estado CREATING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

vi

Resumen

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


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


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


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

horizontalmente simplemente añadiendo nuevos servidores.

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


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


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


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


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

UEC tarball (Ubuntu), VMDK (VMWare), VDI (VirtualBox) o VHD (Microsoft Hyper-

V). Todos los formatos descritos son indicados como formato de disco y/o formato de

contenedor al crear una nueva imagen.

Almacenamiento

Las imágenes en OpenStack son gestionadas por el servicio Glance, que ofrece una

API a través de la cual los usuarios y los administradores pueden realizar acciones sobre

sus imágenes o crear nuevas. Glance se encarga también de la gestión del almacenamien-

to de las imágenes. El servicio de imágenes de Glance soporta los siguientes modos de

almacenamiento en back-end:

Sistema de ficheros

11


Es el modo por defecto y el más simple ya que solo escribe las imágenes en el

propio sistema de ficheros.

Servicio Object StorageUtiliza el servicio de almacenamiento de objetos de OpenStack gestionado por el

servicio Swift para almacenar las imágenes.

Amazon S3En este modo las imágenes se almacenan utilizando el servicio S3 de Amazon, que

es el equivalente a Swift en AWS.

HTTPEn este modo se almacenan las imágenes en un servidor en internet y se accede a

ellas a través de HTTP. Este almacenamiento solo permite modo lectura.

RADOS(Reliable Autonomic Distributed Object Store). Este modo permite almacenar imá-

genes en un servidor de almacenamiento Ceph.

GridFSAlmacena imágenes utilizando el sistema de ficheros de la base de datos no-relacional

MongoDB.

Estados

Las imágenes gestionadas en Glance tienen un estado asociado que varía en función de

la tarea que se esté realizando sobre la imagen o simplemente el estado de almacenamiento

en que se encuentran sus datos. Una imagen puede adoptar los siguientes estados:

QUEUEDEl identificador de imagen se ha reservado para la imagen pero aún no se han subido

datos de imagen a Glance y/o no se indicó explicitamente un tamaño 0 en la creación

de la imagen.

SAVINGLos datos de la imagen se están subiendo al servidor de Glance. Una imagen nunca

estará en este estado si al crearla se indica una localización en vez de subir un

archivo.

ACTIVELa imagen esta completamente lista para ser usada en Glance. Se llega a este estado

12


cuando se acaban de subir los datos de una imagen o si se especifica el tamaño 0 al

crearla.

KILLEDIndica que ha ocurrido un error mientras se subían los datos de la imagen y, por

tanto, la imagen no es legible.

DELETEDGlance aún tiene información de la imagen almacenados pero ya no puede ser usada

y será borrada posteriormente.

PENDING DELETESimilar al estado anterior con la diferencia de que Glance guarda aún los datos de

la imagen. En cualquier caso una imagen en este estado no es recuperable.

En la Figura 2.2 pueden verse las transiciones entre los diferentes estados de una ima-

gen.

2.3.2 Instancias

Una instancia en OpenStack es una máquina virtual desplegada en una nodo físico de

computación. Cada instancia se lanza desde una imagen de máquina virtual y consigue su

capacidad de almacenamiento de volúmenes de almacenamiento de bloques.

Al crearse la instancia, la imagen utilizada como base para la máquina virtual se copia

al servidor desde el almacen de imágenes del servicio Glance. Además, al crear la instan-

cia se le pueden asignar volúmenes de almacenamiento o crear volúmenes efímeros en el

propio disco del servidor. En cualquier caso el disco local es el primero al que accede la

instancia a través del punto de montaje /dev/vda. El proceso de creación de una instancia

puede verse en la Figura 2.3.

Las instancias en OpenStack son gestionadas por el servicio Nova, que permite al

usuario realizar operaciones sobre sus instancias y crear nuevas a partir de imágenes al-

macenadas en Glance. Entre las operaciones permitidas por Nova están las de borrado,

edición, reinicio software, reinicio hardware, cambio de contraseña, adjunto de un volu-

men, adjunto de un grupo de seguridad y ajuste del tamaño de una instancia.

13


Figura 2.2: Diagrama de transiciones entre estados de una imagen

Figura 2.3: Creación de una instancia

Estados

Una instancia en OpenStack tiene tres estados distintos. El primero de ellos es el estado

de la máquina virtual (VM State). Este estado refleja la estabilidad de las llamadas a la

14


API por parte del usuario. Puede adoptar los siguientes valores:

INITIALIZEDLa máquina virtual acaba de ser creada en la base de datos pero aún no se ha cons-

truido.

ACTIVELa instancia esta ejecutándose correctamente con la imagen especificada durante su

creación.

RESCUEDLa instancia esta ejecutándose con la imagen de rescate.

PAUSEDLa instancia se encuentra pausada.

SUSPENDEDLa instancia ha sido suspendida y tiene un snapshot válido de la memoria.

STOPPEDLa instancia no esta ejecutándose y la imagen está en disco.

SOFT DELETEDLa instancia ya no se está ejecutándose en Nova pero la copia de la imagen perma-

nece en el disco y la instancia aún puede ser recuperada.

HARD DELETEDLa instancia ya no existe para el resto de servicios de OpenStack. Posteriormente

tanto la instancia como la copia en disco de la imagen serán destruidas.

RESIZEDEstado de transición mientras el usuario confirma el usuario confirma el cambio de

tamaño de la imagen. La máquina virtual esta parada en el origen y ejecutándose en

el destino.

ERRORHa ocurrido un error irrecuperable. En este estado la única operación que se puede

realizar sobre la instancia es la de borrado.

La Figura 2.4 muestra transiciones entre los estados de una instancia.

El segundo de los estados de la instancia es el power state. Este segundo estado hace

referencia al hypervisor y puede entrar en conflicto con el estado de la máquina virtual

15


Fig

ura

2.4

:D

iagram

ade

estados

de

una

instan

cia

16


descrito anteriormente. Este estado puede tomar tres valores: RUNNING (ejecutándose),

SHUTDOWN (apagado) y NOSTATE (fallo).

Y por último, el estado de tarea (task state) es el que refleja las transiciones entre los

estados de la máquina virtual nombrándolos según las tareas que se estén ejecutando.

Existen 29 valores posibles que puede tomar este estado, pero no se van a detallar todos

ellos ya que en la mayoría de los casos se componen simplemente del nombre de uno de

los estados de máquina virtual más la terminación -ing para denotar la tarea que se está

realizando.

Seguridad y red

Si se añade la instancia a una red de OpenStack, se le puede asignar una dirección

pública a través de la cual el usuario pueda acceder via SSH con la clave RSA indicada al

crear la instancia.

Además, una instancia puede tener asignado un grupo de seguridad que denota los

puertos que son accesibles y desde que direcciones. El usuario puede editar este grupo de

seguridad a través de la API de Nova.

2.3.3 Volúmenes

Un volumen en OpenStack es una unidad de almacenamiento por bloques que puede

ser conectada a una instancia para proporcionar capacidad extra de almacenamiento de

la misma manera que lo haría un disco duro externo. Cada volumen solo puede estar

conectado a una instancia a la vez.

Los volúmenes son gestionados por el servicio Cinder de OpenStack, que permite al

usuario realizar operaciones sobre sus volúmenes así como crear nuevos. Algunas de las

operaciones permitidas por cinder son: editar, borrar, y hacer un snapshot de un volumen.

Estados

El estado de un volumen es reflejo del resultado de alguna operación que se esta reali-

zando o que haya sido realizada sobre él. Los posibles valores del estado de un volumen

son: CREATING, AVAILABLE, IN-USE, ATTACHING, DELETING, ERROR, ERROR

DELETING, BACKING-UP, RESTORING-BACKUP, ERROR RESTORING y ERROR

EXTENDING.

17


Cinder también ofrece la funcionalidad de crear snapshots de volúmenes y gestionar

dichos snapshots.

2.4 Tecnologías de desarrollo web

En este apartado se cubren las tecnologías de desarrollo en web utilizadas en lado

cliente que serán necesarias para la realización del dashboard. Todas las tecnologías y

herramientas aquí recogidas son ampliamente utilizadas en todo el mundo.

2.4.1 HyperText Markup Language (HTML)

HTML [8] es un lenguaje de marcado utilizado para la elaboración de páginas web.

Es también un estándar que define la estructura básica y un código para la definición y

organización del contenido de una página web. El estandar está a cargo del W3C (World

Wide Web Consortium).

El código del lenguaje se estructura en forma de etiquetas rodeadas por corchetes an-

gulates (<, >), llamadas elementos, y de los atributos de dichos elementos. HTML también

puede definir algunos aspectos de la apariencia de un documento y puede incluir o hacer

referencia a un programa (normalmente un script de código JavaScript).

Cualquier usuario puede ver el código HTML de una página web dada seleccionando

la opción Ver código fuente del navegador, en incluso puede modificar la copia local de la

página que ha recibido del servidor, aunque esto no afectará a cómo se muestre la página

a otros usuarios que la soliciten al servidor.

HTML fue definido en 1990 por Tim Berners-Lee, en ese entonces trabajador del Cen-

tro Europeo de Investigaciones Nucleares (CERN), como un subconjunto del conocido

SGML (Standard Generalized Markup Language). Inicialmente fue desarrollado para que

se pudiera compartir fácilmente información entre científicos de diferentes universidades.

Actualmente está en uso la versión 5 de HTML [9]. Esta versión añade nuevos ele-

mentos y atributos cuya funcionalidad era antes realizada por scripts hechos por los desa-

rrolladores. También quedan obsoletos algunos elementos de la anterior versión HTML

4.01.

18


Figura 2.5: Esquema del DOM

2.4.2 JavaScript

JavaScript [6] es un lenguaje de programación interpretado creado por Netscape en

1995 dialecto del estándar ECMAScript [20]. Es un lenguaje interpretado, débilmente

tipado y dinámico, con una orientación a objetos basada en prototipos.

El lenguaje fue llamado inicialmente LiveScript, pero se cambió el nombre tras la

unión de Netscape y Sun Microsystems (creadores de Java). A pesar del nombre, JavaS-

cript no guarda relación alguna con el lenguaje de programación Java.

JavaScript puede ser utilizado tanto en lado servidor como en lado cliente, aunque

tradicionalmente siempre se utilizó en lado cliente en los últimos años ha empezado a

cosechar éxitos en el desarrollo lado servidor debido sobre todo a la aparición de No-

de.js [18]. En lado cliente, JavaScript se usa actualmente para la creación de páginas web

dinámicas.

En el caso del JavaScript de lado cliente, se utiliza el DOM (en español Modelo de

Objetos del Documento) para interactuar con el contenido HTML de la página web de

manera rápida y sencilla. El DOM consiste en una serie de objetos JavaScript creados por

el navegador para representar y acceder a partes del documento HTML que son represen-

tadas como objetos en el código JavaScript. Esto ofrece la capacidad de manejar eventos

19


producidos sobre el DOM tanto por el navegador como por el propio usuario.

2.4.3 JavaScript Object Notation (JSON)

JSON [7] es un formato de texto ligero para el intercambio de datos formado por un

subconjunto de la notación literal de objetos en JavaScript. Al estar basado en literales

de objetos JavaScript y ser más simple que otros formatos usados con el mismo fin como

XML, ha cosechado un gran éxito entre los desarrolladores.

JSON suele ser preferido sobre XML en entornos donde el tamaño del flujo de datos

entre el cliente y el servidor es de vital importancia.

2.4.4 Cascading Style Sheet (CSS)

CSS [12] es el lenguaje utilizado para definir y crear la presentación de un documento

estructurado escrito en HTML o XML. El W3C es el encargado de desarrollar los estándar

de CSS.

CSS tiene una sintaxis muy sencilla que usa palabras tomadas del inglés para definir

los nombres de las propiedades de estilo y sus valores. El lenguaje tiene su propio sistema

de selectores que son los que marcan qué elementos se verán afectados por el bloque de

estilos que sigue a los selectores.

El CSS se puede utilizar tanto incluido en el propio fichero HTML como importado

desde un fichero a parte.

La primera versión de CSS (CSS1) fue publicada en 1996 por el W3C. CSS3 es la

versión actual del estándar CSS y, a diferencia de anteriores versiones está dividida en

documentos separados llamados módulos. Dichos módulos añaden nuevas funcionalida-

des a las definidas en CSS2.

2.4.5 JQuery

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


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.


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


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


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



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


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


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





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-


Escenario 9 Enviar la ID de la instancia seleccionada a través del endpoint de salida

correspondiente

51


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


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.


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


ñ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


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


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


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


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


Ó está realizando una tarea


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




error


de errores

57


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.


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


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


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


Dado un widget que ha recibido una lista de volúmenes

60


Cuando pasan cuatro segundos

Entonces se realiza otra petición de obtención de volúmenes


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


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





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-


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



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.


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


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


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


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


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


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


Escenario 3 Actualizar los datos del widget

Dado un widget de detalles mostrando los atributos de un volumen


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


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


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


68


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




error


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


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


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


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


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


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


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


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


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


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


Figura A.12: Campos para elegir protección visibilidad y region

Instancias

Los pasos a llevar a cabo para crear una nueva instancia son:


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


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


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:


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


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


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


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


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


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


Volúmenes

Figura A.30: Estado

AVAILABLE

Figura A.31: Estado IN-

USE

Figura A.32: Estado

CREATING

91


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,

C=ES

Fecha/Hora Fri Jun 05 11:36:49 CEST 2015

Emisor delCertificado

[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (AdobeSignature)

Dashboard conﬁgurable para la gestión y...

Documents

Transcript of Dashboard conﬁgurable para la gestión y...