diff --git a/taller/docs/PropuestaInstanciaModuloTaller_OpenStack.odt b/taller/docs/PropuestaInstanciaModuloTaller_OpenStack.odt
new file mode 100644
index 0000000000000000000000000000000000000000..cbd58630f06081924ef6911ddfd00a179bfd2ae1
Binary files /dev/null and b/taller/docs/PropuestaInstanciaModuloTaller_OpenStack.odt differ
diff --git a/taller/docs/installation b/taller/docs/installation
new file mode 100644
index 0000000000000000000000000000000000000000..c5a18bb57933ef817912e7c5608d82ccd1fe5af0
--- /dev/null
+++ b/taller/docs/installation
@@ -0,0 +1,351 @@
+Pasos para llevar a cabo la instalación de Openstack Ansible
+
+1) Configuración de redes en virt-manager:
+-- 1.1) Red NAT de management: 10.0.1.0./24
+-- 1.2) Red NAT de storage: 10.0.2.0./24
+-- 1.3) Red NAT de vxlan: 10.0.10.0./24
+
+2) Configurar máquina Deploy
+-- 2.0) Requerimientos:
+---- 2.0.1) vCPUs: 2
+---- 2.0.2) Memoria: 8 GB
+---- 2.0.3) Disco: 40 GB
+---- 2.0.4) SO: CentOS 7 server
+---- 2.0.5) NIC 1: en la red de management con IP 10.0.1.10
+
+-- 2.1) Configurar la interfaz de red eth0: IP y DNS adecuados.
+-- 2.2) Setear en la interfaz del virt-manager, la NAT-OPEN.
+-- 2.3) Cambiar el hostname a 'deploy' en /etc/hostname y mediante el comando $ hostname deploy
+-- 2.4) Configurar las variables de proxy en el /etc/environment con los siguientes comandos:
+ $ echo "http_proxy=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "https_proxy=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "HTTP_PROXY=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "HTTPS_PROXY=http://10.0.1.1:3128" >> /etc/environment
+ $ for env in $( cat /etc/environment ); do export $(echo $env | sed -e 's/"//g'); done
+
+---- 2.4.1) Verificar el acceso a internet mediante el comando $ curl www.google.com
+
+-- 2.5) Instalaciones necesarias
+---- 2.5.1) Actualizar repositorios y reiniciar:
+ $ yum upgrade -y
+ $ reboot
+---- 2.5.2) Instalar repositorio openstack queens:
+ $ yum install -y https://rdoproject.org/repos/openstack-queens/rdo-release-queens.rpm
+---- 2.5.3) Instalar herramientas auxiliares:
+ $ yum install -y git ntp nano net-tools ntpdate openssh-server python-devel sudo '@Development Tools'
+
+-- 2.6) Deshabilitar firewall de CentOS:
+ $ systemctl stop firewalld
+ $ systemctl mask firewalld
+
+-- 2.7) Configurar servicio NTP mediante Chrony, en el archivo /etc/chrony.conf sustituir por las siguientes líneas:
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+
+---- 2.7.1) Restartear el servicio Chrony mediante:
+ $ systemctl restart chronyd
+
+-- 2.8) Clonar el repositorio de Openstack Ansible Queens
+ $ git clone -b 17.1.10 https://git.openstack.org/openstack/openstack-ansible /opt/openstack-ansible
+
+-- 2.9) Instalar openstack-ansible:
+ $ /opt/openstack-ansible/scripts/bootstrap-ansible.sh
+
+-- 2.10) Copiar el contenido de configuración al /etc:
+ $ cp -r /opt/openstack-ansible/etc/openstack_deploy /etc/
+
+-- 2.11) Crear carpeta para log de salidas de la instalación:
+ $ mkdir /var/log/openstack
+
+3) Configurar máquina Infra1
+-- 3.0) Requerimientos:
+---- 3.0.1) vCPUs: 8
+---- 3.0.2) Memoria: 32 GB
+---- 3.0.3) Disco: 40 GB
+---- 3.0.4) NIC 1: en la red de management con IP 10.0.1.11
+---- 3.0.5) NIC 2: en la red de vxlan con IP 10.0.10.11
+---- 3.0.6) NIC 3: en la red de storage con IP 10.0.2.11
+---- 3.0.7) SO: CentOS 7 server
+
+-- 3.1) Configurar las interfaces de red eth0, eth1 y eth2 y los birdges br-mgmt, br-storage y br-vxlan, siguiendo los archivos en /src/infra1/network-scripts.
+-- 3.2) Setear en la interfaces del virt-manager, la NAT-OPEN, la NAT-OPEN-VXLAN y la NAT-OPEN-STORAGE.
+-- 3.3) Cambiar el hostname a 'infra1' en /etc/hostname y mediante el comando $ hostname infra1
+-- 3.4) Configurar las variables de proxy en la sesión pero no en el sistema, porque luego el deploy configura el /etc/environment en todos los nodos.
+ $ export http_proxy=http://10.0.1.1:3128
+ $ export https_proxy=http://10.0.1.1:3128
+ $ export HTTP_PROXY=http://10.0.1.1:3128
+ $ export HTTPS_PROXY=http://10.0.1.1:3128
+
+---- 3.4.1) Verificar el acceso a internet mediante el comando $ curl www.google.com
+
+-- 3.5) Actualizar repositorios y reiniciar:
+ $ yum upgrade -y
+ $ reboot
+-- 3.6) Instalar herramientas auxiliares:
+ $ yum install bridge-utils iputils lsof lvm2 ntp ntpdate openssh-server sudo tcpdump python net-tools nano
+
+-- 3.7) Deshabilitar el Network Manager:
+ $ chkconfig NetworkManager off
+ $ chkconfig network on
+ $ service NetworkManager stop
+ $ service network start
+
+-- 3.8) Deshabilitar el SELinux, cambiando en /etc/sysconfig/selinux, "SELINUX=enforcing" por "SELINUX=disabled"
+
+-- 3.9) Habilitar bonding de interfaces y vlans:
+ $ echo 'bonding' >> /etc/modules-load.d/openstack-ansible.conf
+ $ echo '8021q' >> /etc/modules-load.d/openstack-ansible.conf
+-- 3.10) Configurar servicio NTP mediante Chrony, en el archivo /etc/chrony.conf sustituir por las siguientes líneas:
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+
+---- 3.10.1) Restartear el servicio Chrony mediante:
+ $ systemctl restart chronyd
+-- 3.11) Eliminar reglas de firewall que bloquean el tráfico:
+---- 3.11.1) Eliminar las reglas manualmente:
+ $ iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
+ $ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
+---- 3.11.2) Exportar las reglas a un archivo:
+ $ iptables-save > /etc/sysconfig/iptables
+---- 3.11.3) En cada reboot de la máquina, importar las reglas del archivo anterior:
+ $ iptables-restore < /etc/sysconfig/iptables
+
+
+4 Configurar máquina Compute1
+-- 4.0) Requerimientos:
+---- 4.0.1) vCPUs: 8
+---- 4.0.2) Memoria: 32 GB
+---- 4.0.3) Disco: 40 GB
+---- 4.0.4) NIC 1: en la red de management con IP 10.0.1.12
+---- 4.0.5) NIC 2: en la red de vxlan con IP 10.0.10.12
+---- 4.0.6) NIC 3: en la red de storage con IP 10.0.2.12
+---- 4.0.7) SO: CentOS 7 server
+
+-- 4.1) Configurar las interfaces de red eth0, eth1 y eth2 y los birdges br-mgmt, br-storage y br-vxlan, siguiendo los archivos en /src/compute1/network-scripts.
+-- 4.2) Setear en la interfaces del virt-manager, la NAT-OPEN, la NAT-OPEN-VXLAN y la NAT-OPEN-STORAGE.
+-- 4.3) Cambiar el hostname a 'compute1' en /etc/hostname y mediante el comando $ hostname compute1
+-- 4.4) Configurar las variables de proxy en la sesión pero no en el sistema, porque luego el deploy configura el /etc/environment en todos los nodos.
+ $ export http_proxy=http://10.0.1.1:3128
+ $ export https_proxy=http://10.0.1.1:3128
+ $ export HTTP_PROXY=http://10.0.1.1:3128
+ $ export HTTPS_PROXY=http://10.0.1.1:3128
+---- 4.4.1) Verificar el acceso a internet mediante el comando $ curl www.google.com
+
+-- 4.5) Actualizar repositorios y reiniciar:
+ $ yum upgrade -y
+ $ reboot
+-- 4.6) Instalar herramientas auxiliares:
+ $ yum install -y bridge-utils iputils lsof lvm2 ntp ntpdate openssh-server sudo tcpdump python net-tools nano
+
+-- 4.7) Desahabilitar el Network Manager y levantar bridges:
+ $ chkconfig NetworkManager off
+ $ chkconfig network on
+ $ service NetworkManager stop
+ $ service network start
+
+-- 4.8) Deshabilitar el SELinux, cambiando en /etc/sysconfig/selinux, "SELINUX=enforcing" por "SELINUX=disabled"
+
+-- 4.9) Habilitar bonding de interfaces y vlans:
+ $ echo 'bonding' >> /etc/modules-load.d/openstack-ansible.conf
+ $ echo '8021q' >> /etc/modules-load.d/openstack-ansible.conf
+-- 4.10) Configurar servicio NTP mediante Chrony, en el archivo /etc/chrony.conf sustituir por las siguientes líneas:
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+
+---- 4.10.1) Restartear el servicio Chrony mediante:
+ $ systemctl restart chronyd
+-- 4.11) Eliminar reglas de firewall que bloquean el tráfico:
+---- 4.11.1) Eliminar las reglas manualmente:
+ $ iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
+ $ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
+---- 4.11.2) Exportar las reglas a un archivo:
+ $ iptables-save > /etc/sysconfig/iptables
+---- 4.11.3) En cada reboot de la máquina, importar las reglas del archivo anterior:
+ $ iptables-restore < /etc/sysconfig/iptables
+
+
+5 Configurar máquina Storage1
+-- 5.0) Requerimientos:
+---- 5.0.1) vCPUs: 4
+---- 5.0.2) Memoria: 32 GB
+---- 5.0.3) Disco: 40 GB con SO
+---- 5.0.4) Disco: 200 GB para cinder-volumes
+---- 5.0.5) NIC 1: en la red de management con IP 10.0.1.13
+---- 5.0.6) NIC 2: en la red de storage con IP 10.0.2.13
+---- 5.0.7) SO: CentOS 7 server
+
+-- 5.1) Configurar las interfaces de red eth0 y eth1 y los bridges br-mgmt y br-storage, siguiendo los archivos en /src/storage1/network-scripts.
+-- 5.2) Setear en la interfaces del virt-manager, la NAT-OPEN y la NAT-OPEN-STORAGE.
+-- 5.3) Cambiar el hostname a 'storage1' en /etc/hostname y mediante el comando $ hostname storage1
+-- 5.4) Configurar las variables de proxy en la sesión pero no en el sistema, porque luego el deploy configura el /etc/environment en todos los nodos.
+ $ export http_proxy=http://10.0.1.1:3128
+ $ export https_proxy=http://10.0.1.1:3128
+ $ export HTTP_PROXY=http://10.0.1.1:3128
+ $ export HTTPS_PROXY=http://10.0.1.1:3128
+---- 5.4.1) Verificar el acceso a internet mediante el comando $ curl www.google.com
+
+-- 5.5) Actualizar repositorios y reiniciar:
+ $ yum upgrade -y
+ $ reboot
+-- 5.6) Instalar herramientas auxiliares:
+ $ yum -y install bridge-utils iputils lsof lvm2 ntp ntpdate openssh-server sudo tcpdump python net-tools nano
+
+-- 5.7) Desahabilitar el Network Manager y levantar bridges:
+ $ chkconfig NetworkManager off
+ $ chkconfig network on
+ $ service NetworkManager stop
+ $ service network start
+
+-- 5.8) Deshabilitar el SELinux, cambiando en /etc/sysconfig/selinux, "SELINUX=enforcing" por "SELINUX=disabled"
+
+-- 5.9) Habilitar bonding de interfaces y vlans:
+ $ echo 'bonding' >> /etc/modules-load.d/openstack-ansible.conf
+ $ echo '8021q' >> /etc/modules-load.d/openstack-ansible.conf
+
+-- 5.10) Configurar servicio NTP mediante Chrony, en el archivo /etc/chrony.conf sustituir por las siguientes líneas:
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+---- 5.10.1) Restartear el servicio Chrony mediante:
+ $ systemctl restart chronyd
+
+-- 5.11) Eliminar reglas de firewall que bloquean el tráfico:
+---- 5.11.1) Eliminar las reglas manualmente:
+ $ iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
+ $ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
+---- 5.11.2) Exportar las reglas a un archivo:
+ $ iptables-save > /etc/sysconfig/iptables
+---- 5.11.3) En cada reboot de la máquina, importar las reglas del archivo anterior:
+ $ iptables-restore < /etc/sysconfig/iptables
+
+-- 5.12) Crear el volumen de LVM para utilizar cinder:
+---- 5.12.1) Listar los devices en la máquina:
+ $ lvmdiskscan
+---- 5.12.2) Formatear la pieza física de almacenamiento de 200 GB
+ $ pvcreate --metadatasize 2048 physical_volume_device_path
+---- 5.12.3) Crear el nuevo grupo de almacenamiento que será utilizado por Openstack:
+ $ vgcreate cinder-volumes physical_volume_device_path
+---- 5.12.3) Verificar que el grupo quedó creado correctamente
+ $ vgdisplay
+
+
+6) Configurar máquina HAproxy1
+-- 6.0) Requerimientos:
+---- 6.0.1) vCPUs: 4
+---- 6.0.2) Memoria: 32 GB
+---- 6.0.3) Disco: 40 GB con SO
+---- 6.0.4) NIC 1: en la red externa con IP 192.168.60.160
+---- 6.0.5) NIC 2: en la red de management con IP 10.0.1.15
+---- 6.0.6) SO: CentOS 7 server
+
+-- 6.1) Configurar las interfaces de red eth0 y eth1, siguiendo los archivos en /src/haproxy1/network-scripts.
+-- 6.2) Setear en la interfaces del virt-manager, la NAT-OPEN.
+-- 6.3) Cambiar el hostname a 'haproxy1' en /etc/hostname y mediante el comando $ hostname haproxy1
+-- 6.4) Configurar las variables de proxy en la sesión pero no en el sistema, porque luego el deploy configura el /etc/environment en todos los nodos.
+ $ export http_proxy=http://10.0.1.1:3128
+ $ export https_proxy=http://10.0.1.1:3128
+ $ export HTTP_PROXY=http://10.0.1.1:3128
+ $ export HTTPS_PROXY=http://10.0.1.1:3128
+---- 6.4.1) Verificar el acceso a internet mediante el comando $ curl www.google.com
+
+-- 6.5) Actualizar repositorios y reiniciar:
+ $ yum upgrade -y
+ $ reboot
+-- 6.6) Instalar herramientas auxiliares:
+ $ yum install bridge-utils iputils lsof lvm2 ntp ntpdate openssh-server sudo tcpdump python net-tools nano libsemanage-python
+
+-- 6.7) Deshabilitar el SELinux, cambiando en /etc/sysconfig/selinux, "SELINUX=enforcing" por "SELINUX=disabled"
+
+-- 6.8) Habilitar bonding de interfaces y vlans:
+ $ echo 'bonding' >> /etc/modules-load.d/openstack-ansible.conf
+ $ echo '8021q' >> /etc/modules-load.d/openstack-ansible.conf
+
+-- 6.9) Configurar servicio NTP mediante Chrony, en el archivo /etc/chrony.conf sustituir por las siguientes líneas:
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+---- 6.9.1) Restartear el servicio Chrony mediante:
+ $ systemctl restart chronyd
+
+-- 6.10) Eliminar reglas de firewall que bloquean el tráfico:
+---- 6.10.1) Eliminar las reglas manualmente:
+ $ iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
+ $ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
+---- 6.10.2) Exportar las reglas a un archivo:
+ $ iptables-save > /etc/sysconfig/iptables
+---- 6.10.3) En cada reboot de la máquina, importar las reglas del archivo anterior:
+ $ iptables-restore < /etc/sysconfig/iptables
+
+
+
+
+7) Pre instalación
+-- 7.1) Configurar claves SSH
+---- 7.1.1) Generar una nueva clave con todas las opciones por defecto y sin password:
+ $ ssh-keygen
+
+---- 7.1.2) Copiar la clave SSH a todos los host target:
+ $ ssh-copy-id root@10.0.1.11
+ $ ssh-copy-id root@10.0.1.12
+ $ ssh-copy-id root@10.0.1.13
+ $ ssh-copy-id root@10.0.1.15
+
+-- 7.2) Configurar la playbook principal de openstack en /etc/openstack_deploy/openstack_user_confing.yml, tal como se encuentra en src/deploy/opestack_user_config_prod.yml.
+
+-- 7.3) Configurar las variables de usuario en /etc/openstack_deploy/user_variables.yml para la utilización de proxy, tal como se encuentra en src/deploy/user_variables.yml.
+
+-- 7.4) En caso de utilizar un backend de storage LVM se debe indicar que este debe ser deployado en metal,
+ para esto se debe configurar el archivo /etc/openstack_deploy/env.d/cinder.yml con lo siguiente (se encuentra en src/deploy/cinder.yml):
+ container_skel:
+ cinder_volumes_container:
+ properties:
+ is_metal: false
+
+-- 7.5) Configurar los secretos de openstack:
+ $ cd /opt/openstack-ansible
+ $ ./scripts/pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml
+
+
+-- 7.6) Aplicar el commit de Rookie sobre Queens para evitar problema de SELinux
+ https://bugs.launchpad.net/openstack-ansible/+bug/1782798
+ https://review.opendev.org/#/c/603860/
+
+---- 7.6.1) Eliminar los siguientes archivos:
+ $ rm /etc/ansible/roles/os_nova/files/osa-nova.te
+ $ rm /etc/ansible/roles/os_nova/tasks/nova_selinux.yml
+
+---- 7.6.2) Modificar el archivo /etc/ansible/roles/os_nova/tasks/nova_post_install.yml eliminando las siguientes líneas:
+ - include_tasks: nova_selinux.yml
+ when:
+ - ansible_selinux.status == "enabled"
+
+
+
+
+8) Instalación
+-- 8.1) Revisar la sintaxis de las playbooks posicionado en /opt/openstack-ansible/playbooks:
+ $ openstack-ansible setup-hosts.yml --syntax-check
+ $ openstack-ansible setup-infrastructure.yml --syntax-check
+ $ openstack-ansible setup-openstack.yml --syntax-check
+
+-- 8.2) Ejecutar las playbooks enviando la salida al archivo de log correspondiente (recordar aumentar la numeración en XX) posicionado en /opt/openstack-ansible/playbooks:
+ $ openstack-ansible -vvv setup-hosts.yml 2>&1 | tee /var/log/openstack/hostsXX.log
+ $ openstack-ansible -vvv haproxy-install.yml 2>&1 | tee /var/log/openstack/haproxyXX.log
+ $ openstack-ansible -vvv setup-infrastructure.yml 2>&1 | tee /var/log/openstack/infrastructureXX.log
+ $ openstack-ansible -vvv setup-openstack.yml 2>&1 | tee /var/log/openstack/openstackXX.log
+
+
+
+
+
+
+------ AGREGAR INFO DEL COMMIT
+https://github.com/openstack/openstack-ansible-lxc_hosts/commit/43e61820f42d88f36ec0ab4865800cbb4b1076ae#diff-a32feedfc0fe75301cf2f812b316e6a2R27
diff --git a/taller/docs/latex/.gitignore b/taller/docs/latex/.gitignore
new file mode 100644
index 0000000000000000000000000000000000000000..adbc2fde039ec03063f237b88ec8a4b56568346a
--- /dev/null
+++ b/taller/docs/latex/.gitignore
@@ -0,0 +1,7 @@
+report.aux
+report.bbl
+report.blg
+report.log
+report.out
+report.synctex.gz
+texput.log
diff --git a/taller/docs/latex/references.bib b/taller/docs/latex/references.bib
new file mode 100644
index 0000000000000000000000000000000000000000..f6b4f1dfe5fe6bdc476af43c4ae5401fa66363c3
--- /dev/null
+++ b/taller/docs/latex/references.bib
@@ -0,0 +1,515 @@
+% ---------- Oficiales ------------
+@Misc{802.1Q,
+title = {{802.1Q-2014 - Bridges and Bridged Networks}},
+howpublished = {\url{http://www.ieee802.org/1/pages/802.1Q-2014.html}},
+note = {Accedido: 2019-06-15}
+}
+
+@Misc{openstack-basic-networking,
+title = {{Basic networking}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/mitaka/networking-guide/intro-basic-networking.html}},
+note = {Accedido: 2019-06-15}
+}
+
+@Misc{openstack-networking-concepts,
+title = {{Networking concepts}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/arch-design/design-networking/design-networking-concepts.html}},
+note = {Accedido: 2019-06-15}
+}
+
+@Misc{openstack-history,
+title = {{Introduction}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/project-team-guide/introduction.html}},
+note = {Accedido: 2019-06-15}
+}
+
+@Misc{openstack-software,
+title = {{Software}},
+author = {{Openstack}},
+howpublished = {\url{https://www.openstack.org/software/}},
+note = {Accedido: 2019-06-15}
+}
+
+@Misc{openstack-keystone-architecture,
+title = {{Keystone Architecture}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/keystone/latest/getting-started/architecture.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@book{openstack-idm-book,
+ author = {Martinelli, Steve and Nash, Henry and Topol, Brad},
+ title = {Identity, Authentication, and Access Management in OpenStack: Implementing and Deploying Keystone},
+ year = {2015},
+ isbn = {1491941200, 9781491941201},
+ edition = {1st},
+ publisher = {O'Reilly Media, Inc.}
+}
+
+@InBook{openstack-idm-book-1,
+ author = {Martinelli, Steve and Nash, Henry and Topol, Brad},
+ title = {Identity, Authentication, and Access Management in OpenStack: Implementing and Deploying Keystone},
+ year = {2015},
+ edition = {1st},
+ isbn = {1491941200, 9781491941201},
+ chapter = {1 Fundamental Keystone Topics},
+ pages = {13},
+ publisher = {O'Reilly Media, Inc.}
+}
+
+
+@InBook{openstack-deploying-book,
+ author = {Pepple, Ken},
+ title = {Deploying OpenStack},
+ year = {2011},
+ isbn = {9781449311223},
+ chapter = {4 Understanding Nova},
+ publisher = {O'Reilly Media, Inc.}
+}
+
+@InBook{openstack-networking-book-1,
+ author = {Denton, James},
+ title = {Learning Openstack Networking},
+ year = {2018},
+ isbn = {9781788392495},
+ edition = {3rd},
+ chapter = {1 Introduction to Openstack Networking},
+ pages = {21-23},
+ publisher = {Packt Publishing}
+}
+
+@InBook{openstack-networking-book-2,
+ author = {Denton, James},
+ title = {Learning Openstack Networking},
+ year = {2018},
+ isbn = {9781788392495},
+ edition = {3rd},
+ chapter = {1 Introduction to Openstack Networking},
+ pages = {15},
+ publisher = {Packt Publishing}
+}
+
+@InBook{openstack-networking-book-3,
+ author = {Denton, James},
+ title = {Learning Openstack Networking},
+ year = {2018},
+ isbn = {9781788392495},
+ edition = {3rd},
+ chapter = {1 Introduction to Openstack Networking},
+ publisher = {Packt Publishing}
+}
+
+@InBook{openstack-networking-book-4,
+ author = {Denton, James},
+ title = {Learning Openstack Networking},
+ year = {2018},
+ isbn = {9781788392495},
+ edition = {3rd},
+ chapter = {1 Introduction to Openstack Networking},
+ pages = {31},
+ publisher = {Packt Publishing}
+}
+
+@InBook{openstack-architects-book,
+ author = {Silverman, Ben and Solberg, Michael},
+ title = {Openstack for Architects},
+ year = {2018},
+ isbn = {9781788624510},
+ edition = {2nd},
+ chapter = {3 Planning for Failure and Success},
+ pages = {37},
+ publisher = {Packt Publishing}
+}
+
+@InBook{openstack-cookbook-book,
+ author = {Jackson, Kevin and Bunch, Cody and Sigler, Egle and Denton, James},
+ title = {Openstack Cloud Computing Cookbook},
+ year = {2018},
+ isbn = {9781788398763},
+ edition = {4th},
+ chapter = {1 Installing Openstack with Ansible},
+ pages = {16},
+ publisher = {Packt Publishing}
+}
+
+@Misc{openstack-design,
+title = {{Design}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/arch-design/design.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-control-plane,
+title = {{Control plane architecture}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/arch-design/design-control-plane.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-conductor,
+title = {{Conductor as a place for orchestrating tasks}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/nova/rocky/user/conductor.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-compute-overview,
+title = {{Compute service overview}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/nova/latest/install/get-started-compute.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-memcached,
+title = {{Memcached}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/mitaka/install-guide-ubuntu/environment-memcached.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-messaging,
+title = {{Message queuing}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/security-guide/messaging.htmll}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-lvm,
+title = {{LVM}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/cinder/latest/configuration/block-storage/drivers/lvm-volume-driver.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-volume-drivers,
+title = {{Volume drivers}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/cinder/latest/configuration/block-storage/volume-drivers.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-inventory,
+title = {{Iventory}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/openstack-ansible/rocky/reference/inventory/inventory.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-user-config,
+title = {{openstack\_user\_config settings reference}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/openstack-ansible/queens/reference/inventory/openstack-user-config-reference.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-image-properties-1,
+title = {{Common Image Properties}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/glance/queens/user/common-image-properties.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-image-properties-2,
+title = {{Useful image properties}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/glance/latest/admin/useful-image-properties.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-images-instances,
+title = {{Images and instances}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/glance/queens/admin/troubleshooting.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{openstack-storage-api,
+title = {{Object Storage API overview}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/swift/latest/api/object_api_v1_overview.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-storage-characteristics,
+title = {{Object Storage characteristics}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/swift/latest/admin/objectstorage-characteristics.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-storage-intro,
+title = {{Introduction to Object Storage}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/swift/latest/admin/objectstorage-intro.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-storage-components,
+title = {{Components}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/swift/latest/admin/objectstorage-components.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-storage-architect,
+title = {{Swift Architectural Overview}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/swift/latest/overview_architecture.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-puppet,
+title = {{Welcome to the Puppet OpenStack Guide!}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/puppet-openstack-guide/latest/}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-ansible,
+title = {{OpenStack-Ansible Documentation}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/openstack-ansible/latest/}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-marketplace,
+title = {{The OpenStack Marketplace}},
+author = {{Openstack}},
+howpublished = {\url{https://www.openstack.org/marketplace/distros/}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-nova-architecture,
+title = {{Nova System Architecture}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/nova/latest/user/architecture.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-glance-architecture,
+title = {{Basic architecture}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/glance/queens/contributor/architecture.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-container-networking,
+title = {{Container networking}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/openstack-ansible/rocky/reference/architecture/container-networking.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-networking-architecture,
+title = {{Network architectures}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/openstack-ansible/stein/user/network-arch/example.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-appendix-e,
+title = {{Appendix E: Container networking}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/project-deploy-guide/openstack-ansible/ocata/app-networking.html#network-diagrams}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-selinux-fix-1,
+title = {{AIO Build Fails on SELinux File Context Tasks}},
+author = {{Openstack}},
+howpublished = {\url{https://bugs.launchpad.net/openstack-ansible/+bug/1782798}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-selinux-fix-2,
+title = {{Drop SELinux support for CentOS 7}},
+author = {{Openstack}},
+howpublished = {\url{https://review.opendev.org/#/c/603860/}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{openstack-projects-users,
+title = {{Manage projects and users}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/horizon/latest/admin/manage-projects-and-users.html}},
+note = {Accedido: 2019-08-03}
+}
+
+@Misc{openstack-manage-flavors,
+title = {{Manage flavors}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/horizon/latest/admin/manage-flavors.html}},
+note = {Accedido: 2019-08-03}
+}
+
+@Misc{openstack-settings-reference,
+title = {{Settings Reference}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/horizon/queens/configuration/settings.html}},
+note = {Accedido: 2019-08-04}
+}
+
+@Misc{openstack-obtain-images,
+title = {{Get images}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/image-guide/obtain-images.html}},
+note = {Accedido: 2019-08-04}
+}
+
+@Misc{openstack-manage-networks,
+title = {{Create and manage networks}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/horizon/latest/user/create-networks.html}},
+note = {Accedido: 2019-08-03}
+}
+
+@Misc{openstack-security-instances,
+title = {{Configure access and security for instances}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/horizon/latest/user/configure-access-and-security-for-instances.html}},
+note = {Accedido: 2019-08-03}
+}
+
+@Misc{openstack-manage-instances,
+title = {{Launch and manage instances}},
+author = {{Openstack}},
+howpublished = {\url{https://docs.openstack.org/horizon/latest/user/launch-instances.html}},
+note = {Accedido: 2019-08-03}
+}
+
+@Misc{ansible-modules,
+title = {{Module Index}},
+author = {{Ansible}},
+howpublished = {\url{https://docs.ansible.com/ansible/latest/modules/modules_by_category.html}},
+note = {Accedido: 2019-07-05}
+}
+
+@Misc{redhat-virtualization,
+title = {{What is virtualization?}},
+author = {{Red Hat}},
+howpublished = {\url{https://www.redhat.com/en/topics/virtualization/what-is-virtualization}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{redhat-kvm,
+title = {{What is KVM?}},
+author = {{Red Hat}},
+howpublished = {\url{https://www.redhat.com/en/topics/virtualization/what-is-KVM}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{redhat-lxc,
+title = {{What's a Linux container}},
+author = {{Red Hat}},
+howpublished = {\url{https://www.redhat.com/en/topics/containers/whats-a-linux-container}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{redhat-conductor,
+title = {{Conductor}},
+author = {{Red Hat}},
+howpublished = {\url{https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/Configuration_Reference_Guide/section_conductor.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{redhat-cinder,
+title = {{Openstack Block Storage (Cinder)}},
+author = {{Red Hat}},
+howpublished = {\url{https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html/Component_Overview/section-blockStorage.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{arch-lxc,
+title = {{Linux Containers}},
+author = {{ArchLinux}},
+howpublished = {\url{https://wiki.archlinux.org/index.php/Linux_Containers}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{vmware-virtualization,
+title = {{Virtualization}},
+author = {{VMware}},
+howpublished = {\url{https://www.vmware.com/solutions/virtualization.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@TechReport{vmware-whitepaper,
+year = {2018},
+title = {{Containers on Virtual Machines or Bare Metal?}},
+ author = {},
+ type = {{White Paper}},
+ institution = {{VMware}}
+}
+
+@Misc{oracle-hypervisors,
+title = {{What are Hypervisors?}},
+author = {{Oracle}},
+howpublished = {\url{https://docs.oracle.com/cd/E50245_01/E50249/html/vmcon-hypervisor.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{docker-containers,
+title = {{What is a Container?}},
+author = {{Docker}},
+howpublished = {\url{https://www.docker.com/resources/what-container}},
+note = {Accedido: 2019-06-20}
+}
+
+@Misc{cisco-datacenter,
+title = {{What is a Data Center}},
+author = {{Cisco}},
+howpublished = {\url{https://www.cisco.com/c/en/us/solutions/data-center-virtualization/what-is-a-data-center.html}},
+note = {Accedido: 2019-06-20}
+}
+
+@TechReport{sp800-145,
+ author = {Mell, Peter M. and Grance, Timothy},
+ title = {{SP 800-145, The NIST Definition of Cloud Computing}},
+ type = {{Special Publication}},
+ year = {2011},
+ institution = {{National Institute of Standards \& Technology}}
+}
+
+@TechReport{sp800-190,
+author = {Souppaya, Murugiah and Morello, John and Scarfone, Karen},
+year = {2017},
+type = {{Special Publication}},
+institution = {{National Institute of Standards \& Technology}},
+title = {{SP 800-190, Application Container Security Guide}},
+doi = {10.6028/NIST.SP.800-190}
+}
+
+@Article{Zhang2010,
+author="Zhang, Qi
+and Cheng, Lu
+and Boutaba, Raouf",
+title="Cloud computing: state-of-the-art and research challenges",
+journal="Journal of Internet Services and Applications",
+year="2010",
+month="May",
+day="01",
+volume="1",
+number="1",
+abstract="Cloud computing has recently emerged as a new paradigm for hosting and delivering services over the Internet. Cloud computing is attractive to business owners as it eliminates the requirement for users to plan ahead for provisioning, and allows enterprises to start from the small and increase resources only when there is a rise in service demand. However, despite the fact that cloud computing offers huge opportunities to the IT industry, the development of cloud computing technology is currently at its infancy, with many issues still to be addressed. In this paper, we present a survey of cloud computing, highlighting its key concepts, architectural principles, state-of-the-art implementation as well as research challenges. The aim of this paper is to provide a better understanding of the design challenges of cloud computing and identify important research directions in this increasingly important area.",
+issn="1869-0238",
+doi="10.1007/s13174-010-0007-6",
+url="https://doi.org/10.1007/s13174-010-0007-6"
+}
+
+@misc{rfc7348,
+ series = {Request for Comments},
+ number = 7348,
+ howpublished = {RFC 7348},
+ publisher = {RFC Editor},
+ doi = {10.17487/RFC7348},
+ url = {https://rfc-editor.org/rfc/rfc7348.txt},
+ author = {Mallik Mahalingam and Dinesh Dutt and Kenneth Duda and Puneet Agarwal and Larry Kreeger and T. Sridhar and Mike Bursell and Chris Wright},
+ title = {{Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks}},
+ pagetotal = 22,
+ year = 2014,
+ month = aug,
+ abstract = {This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.}
+}
diff --git a/taller/docs/latex/report.bcf b/taller/docs/latex/report.bcf
new file mode 100644
index 0000000000000000000000000000000000000000..54cdf729bcf7b9e0feb0b9dbdfed9fafa31af0ca
--- /dev/null
+++ b/taller/docs/latex/report.bcf
@@ -0,0 +1,1972 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<bcf:controlfile version="3.4" bltxversion="3.10" xmlns:bcf="https://sourceforge.net/projects/biblatex">
+ <!-- BIBER OPTIONS -->
+ <bcf:options component="biber" type="global">
+ <bcf:option type="singlevalued">
+ <bcf:key>output_encoding</bcf:key>
+ <bcf:value>utf8</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>input_encoding</bcf:key>
+ <bcf:value>utf8</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>debug</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>mincrossrefs</bcf:key>
+ <bcf:value>2</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>minxrefs</bcf:key>
+ <bcf:value>2</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>sortcase</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>sortupper</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ </bcf:options>
+ <!-- BIBLATEX OPTIONS -->
+ <!-- GLOBAL -->
+ <bcf:options component="biblatex" type="global">
+ <bcf:option type="singlevalued">
+ <bcf:key>alphaothers</bcf:key>
+ <bcf:value>+</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>labelalpha</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="multivalued">
+ <bcf:key>labelnamespec</bcf:key>
+ <bcf:value order="1">shortauthor</bcf:value>
+ <bcf:value order="2">author</bcf:value>
+ <bcf:value order="3">shorteditor</bcf:value>
+ <bcf:value order="4">editor</bcf:value>
+ <bcf:value order="5">translator</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>labeltitle</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="multivalued">
+ <bcf:key>labeltitlespec</bcf:key>
+ <bcf:value order="1">shorttitle</bcf:value>
+ <bcf:value order="2">title</bcf:value>
+ <bcf:value order="3">maintitle</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>labeltitleyear</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>labeldateparts</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="multivalued">
+ <bcf:key>labeldatespec</bcf:key>
+ <bcf:value order="1" type="field">date</bcf:value>
+ <bcf:value order="2" type="field">year</bcf:value>
+ <bcf:value order="3" type="field">eventdate</bcf:value>
+ <bcf:value order="4" type="field">origdate</bcf:value>
+ <bcf:value order="5" type="field">urldate</bcf:value>
+ <bcf:value order="6" type="string">nodate</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>julian</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>gregorianstart</bcf:key>
+ <bcf:value>1582-10-15</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>maxalphanames</bcf:key>
+ <bcf:value>3</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>maxbibnames</bcf:key>
+ <bcf:value>3</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>maxcitenames</bcf:key>
+ <bcf:value>3</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>maxitems</bcf:key>
+ <bcf:value>3</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>minalphanames</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>minbibnames</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>mincitenames</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>minitems</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>singletitle</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>sortalphaothers</bcf:key>
+ <bcf:value>+</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>sortlocale</bcf:key>
+ <bcf:value>spanish</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>sortingtemplatename</bcf:key>
+ <bcf:value>nty</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>sortsets</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>uniquelist</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>uniquename</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>uniqueprimaryauthor</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>uniquetitle</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>uniquebaretitle</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>uniquework</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useprefix</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useafterword</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useannotator</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useauthor</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>usebookauthor</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>usecommentator</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useeditor</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useeditora</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useeditorb</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useeditorc</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useforeword</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useholder</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useintroduction</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>usenamea</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>usenameb</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>usenamec</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>usetranslator</bcf:key>
+ <bcf:value>0</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useshortauthor</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ <bcf:option type="singlevalued">
+ <bcf:key>useshorteditor</bcf:key>
+ <bcf:value>1</bcf:value>
+ </bcf:option>
+ </bcf:options>
+ <!-- BIBLATEX OPTION SCOPE -->
+ <bcf:optionscope type="GLOBAL">
+ <bcf:option datatype="xml">datamodel</bcf:option>
+ <bcf:option datatype="xml">labelalphanametemplate</bcf:option>
+ <bcf:option datatype="xml">labelalphatemplate</bcf:option>
+ <bcf:option datatype="xml">inheritance</bcf:option>
+ <bcf:option datatype="xml">translit</bcf:option>
+ <bcf:option datatype="xml">uniquenametemplate</bcf:option>
+ <bcf:option datatype="xml">sortingnamekeytemplate</bcf:option>
+ <bcf:option datatype="xml">sortingtemplate</bcf:option>
+ <bcf:option datatype="xml">extradatespec</bcf:option>
+ <bcf:option datatype="xml">labelnamespec</bcf:option>
+ <bcf:option datatype="xml">labeltitlespec</bcf:option>
+ <bcf:option datatype="xml">labeldatespec</bcf:option>
+ <bcf:option datatype="string">controlversion</bcf:option>
+ <bcf:option datatype="string">alphaothers</bcf:option>
+ <bcf:option datatype="string">sortalphaothers</bcf:option>
+ <bcf:option datatype="string">presort</bcf:option>
+ <bcf:option datatype="string">texencoding</bcf:option>
+ <bcf:option datatype="string">bibencoding</bcf:option>
+ <bcf:option datatype="string">sortingtemplatename</bcf:option>
+ <bcf:option datatype="string">sortlocale</bcf:option>
+ <bcf:option datatype="string">language</bcf:option>
+ <bcf:option datatype="string">autolang</bcf:option>
+ <bcf:option datatype="string">backrefsetstyle</bcf:option>
+ <bcf:option datatype="string">block</bcf:option>
+ <bcf:option datatype="string">labeldate</bcf:option>
+ <bcf:option datatype="string">labeltime</bcf:option>
+ <bcf:option datatype="string">dateera</bcf:option>
+ <bcf:option datatype="string">date</bcf:option>
+ <bcf:option datatype="string">time</bcf:option>
+ <bcf:option datatype="string">eventdate</bcf:option>
+ <bcf:option datatype="string">eventtime</bcf:option>
+ <bcf:option datatype="string">origdate</bcf:option>
+ <bcf:option datatype="string">origtime</bcf:option>
+ <bcf:option datatype="string">urldate</bcf:option>
+ <bcf:option datatype="string">urltime</bcf:option>
+ <bcf:option datatype="string">alldatesusetime</bcf:option>
+ <bcf:option datatype="string">alldates</bcf:option>
+ <bcf:option datatype="string">alltimes</bcf:option>
+ <bcf:option datatype="string">gregorianstart</bcf:option>
+ <bcf:option datatype="string">autocite</bcf:option>
+ <bcf:option datatype="string">notetype</bcf:option>
+ <bcf:option datatype="string">refsection</bcf:option>
+ <bcf:option datatype="string">refsegment</bcf:option>
+ <bcf:option datatype="string">citereset</bcf:option>
+ <bcf:option datatype="string">sortlos</bcf:option>
+ <bcf:option datatype="string">babel</bcf:option>
+ <bcf:option datatype="string">datelabel</bcf:option>
+ <bcf:option datatype="string">backrefstyle</bcf:option>
+ <bcf:option datatype="string">arxiv</bcf:option>
+ <bcf:option datatype="boolean">familyinits</bcf:option>
+ <bcf:option datatype="boolean">giveninits</bcf:option>
+ <bcf:option datatype="boolean">prefixinits</bcf:option>
+ <bcf:option datatype="boolean">suffixinits</bcf:option>
+ <bcf:option datatype="boolean">useafterword</bcf:option>
+ <bcf:option datatype="boolean">useannotator</bcf:option>
+ <bcf:option datatype="boolean">useauthor</bcf:option>
+ <bcf:option datatype="boolean">usebookauthor</bcf:option>
+ <bcf:option datatype="boolean">usecommentator</bcf:option>
+ <bcf:option datatype="boolean">useeditor</bcf:option>
+ <bcf:option datatype="boolean">useeditora</bcf:option>
+ <bcf:option datatype="boolean">useeditorb</bcf:option>
+ <bcf:option datatype="boolean">useeditorc</bcf:option>
+ <bcf:option datatype="boolean">useforeword</bcf:option>
+ <bcf:option datatype="boolean">useholder</bcf:option>
+ <bcf:option datatype="boolean">useintroduction</bcf:option>
+ <bcf:option datatype="boolean">usenamea</bcf:option>
+ <bcf:option datatype="boolean">usenameb</bcf:option>
+ <bcf:option datatype="boolean">usenamec</bcf:option>
+ <bcf:option datatype="boolean">usetranslator</bcf:option>
+ <bcf:option datatype="boolean">useshortauthor</bcf:option>
+ <bcf:option datatype="boolean">useshorteditor</bcf:option>
+ <bcf:option datatype="boolean">debug</bcf:option>
+ <bcf:option datatype="boolean">loadfiles</bcf:option>
+ <bcf:option datatype="boolean">safeinputenc</bcf:option>
+ <bcf:option datatype="boolean">sortcase</bcf:option>
+ <bcf:option datatype="boolean">sortupper</bcf:option>
+ <bcf:option datatype="boolean">terseinits</bcf:option>
+ <bcf:option datatype="boolean">abbreviate</bcf:option>
+ <bcf:option datatype="boolean">dateabbrev</bcf:option>
+ <bcf:option datatype="boolean">clearlang</bcf:option>
+ <bcf:option datatype="boolean">indexing</bcf:option>
+ <bcf:option datatype="boolean">sortcites</bcf:option>
+ <bcf:option datatype="boolean">sortsets</bcf:option>
+ <bcf:option datatype="boolean">hyperref</bcf:option>
+ <bcf:option datatype="boolean">backref</bcf:option>
+ <bcf:option datatype="boolean">pagetracker</bcf:option>
+ <bcf:option datatype="boolean">citecounter</bcf:option>
+ <bcf:option datatype="boolean">citetracker</bcf:option>
+ <bcf:option datatype="boolean">ibidtracker</bcf:option>
+ <bcf:option datatype="boolean">idemtracker</bcf:option>
+ <bcf:option datatype="boolean">opcittracker</bcf:option>
+ <bcf:option datatype="boolean">loccittracker</bcf:option>
+ <bcf:option datatype="boolean">parentracker</bcf:option>
+ <bcf:option datatype="boolean">labeldateusetime</bcf:option>
+ <bcf:option datatype="boolean">datecirca</bcf:option>
+ <bcf:option datatype="boolean">dateuncertain</bcf:option>
+ <bcf:option datatype="boolean">dateusetime</bcf:option>
+ <bcf:option datatype="boolean">eventdateusetime</bcf:option>
+ <bcf:option datatype="boolean">origdateusetime</bcf:option>
+ <bcf:option datatype="boolean">urldateusetime</bcf:option>
+ <bcf:option datatype="boolean">julian</bcf:option>
+ <bcf:option datatype="boolean">datezeros</bcf:option>
+ <bcf:option datatype="boolean">timezeros</bcf:option>
+ <bcf:option datatype="boolean">timezones</bcf:option>
+ <bcf:option datatype="boolean">seconds</bcf:option>
+ <bcf:option datatype="boolean">autopunct</bcf:option>
+ <bcf:option datatype="boolean">punctfont</bcf:option>
+ <bcf:option datatype="boolean">labelnumber</bcf:option>
+ <bcf:option datatype="boolean">labelalpha</bcf:option>
+ <bcf:option datatype="boolean">labeltitle</bcf:option>
+ <bcf:option datatype="boolean">labeltitleyear</bcf:option>
+ <bcf:option datatype="boolean">labeldateparts</bcf:option>
+ <bcf:option datatype="boolean">uniquelist</bcf:option>
+ <bcf:option datatype="boolean">uniquename</bcf:option>
+ <bcf:option datatype="boolean">singletitle</bcf:option>
+ <bcf:option datatype="boolean">uniquetitle</bcf:option>
+ <bcf:option datatype="boolean">uniquebaretitle</bcf:option>
+ <bcf:option datatype="boolean">uniquework</bcf:option>
+ <bcf:option datatype="boolean">uniqueprimaryauthor</bcf:option>
+ <bcf:option datatype="boolean">defernumbers</bcf:option>
+ <bcf:option datatype="boolean">bibwarn</bcf:option>
+ <bcf:option datatype="boolean">useprefix</bcf:option>
+ <bcf:option datatype="boolean">defernums</bcf:option>
+ <bcf:option datatype="boolean">firstinits</bcf:option>
+ <bcf:option datatype="boolean">sortfirstinits</bcf:option>
+ <bcf:option datatype="boolean">sortgiveninits</bcf:option>
+ <bcf:option datatype="boolean">labelyear</bcf:option>
+ <bcf:option datatype="boolean">isbn</bcf:option>
+ <bcf:option datatype="boolean">url</bcf:option>
+ <bcf:option datatype="boolean">doi</bcf:option>
+ <bcf:option datatype="boolean">eprint</bcf:option>
+ <bcf:option datatype="boolean">related</bcf:option>
+ <bcf:option datatype="boolean">subentry</bcf:option>
+ <bcf:option datatype="integer">mincrossrefs</bcf:option>
+ <bcf:option datatype="integer">minxrefs</bcf:option>
+ <bcf:option datatype="integer">maxnames</bcf:option>
+ <bcf:option datatype="integer">minnames</bcf:option>
+ <bcf:option datatype="integer">maxbibnames</bcf:option>
+ <bcf:option datatype="integer">minbibnames</bcf:option>
+ <bcf:option datatype="integer">maxcitenames</bcf:option>
+ <bcf:option datatype="integer">mincitenames</bcf:option>
+ <bcf:option datatype="integer">maxitems</bcf:option>
+ <bcf:option datatype="integer">minitems</bcf:option>
+ <bcf:option datatype="integer">maxalphanames</bcf:option>
+ <bcf:option datatype="integer">minalphanames</bcf:option>
+ <bcf:option datatype="integer">maxparens</bcf:option>
+ <bcf:option datatype="integer">dateeraauto</bcf:option>
+ </bcf:optionscope>
+ <bcf:optionscope type="ENTRYTYPE">
+ <bcf:option datatype="string">alphaothers</bcf:option>
+ <bcf:option datatype="string">sortalphaothers</bcf:option>
+ <bcf:option datatype="string">presort</bcf:option>
+ <bcf:option datatype="boolean">useafterword</bcf:option>
+ <bcf:option datatype="boolean">useannotator</bcf:option>
+ <bcf:option datatype="boolean">useauthor</bcf:option>
+ <bcf:option datatype="boolean">usebookauthor</bcf:option>
+ <bcf:option datatype="boolean">usecommentator</bcf:option>
+ <bcf:option datatype="boolean">useeditor</bcf:option>
+ <bcf:option datatype="boolean">useeditora</bcf:option>
+ <bcf:option datatype="boolean">useeditorb</bcf:option>
+ <bcf:option datatype="boolean">useeditorc</bcf:option>
+ <bcf:option datatype="boolean">useforeword</bcf:option>
+ <bcf:option datatype="boolean">useholder</bcf:option>
+ <bcf:option datatype="boolean">useintroduction</bcf:option>
+ <bcf:option datatype="boolean">usenamea</bcf:option>
+ <bcf:option datatype="boolean">usenameb</bcf:option>
+ <bcf:option datatype="boolean">usenamec</bcf:option>
+ <bcf:option datatype="boolean">usetranslator</bcf:option>
+ <bcf:option datatype="boolean">useshortauthor</bcf:option>
+ <bcf:option datatype="boolean">useshorteditor</bcf:option>
+ <bcf:option datatype="boolean">indexing</bcf:option>
+ <bcf:option datatype="boolean">labelnumber</bcf:option>
+ <bcf:option datatype="boolean">labelalpha</bcf:option>
+ <bcf:option datatype="boolean">labeltitle</bcf:option>
+ <bcf:option datatype="boolean">labeltitleyear</bcf:option>
+ <bcf:option datatype="boolean">labeldateparts</bcf:option>
+ <bcf:option datatype="boolean">uniquelist</bcf:option>
+ <bcf:option datatype="boolean">uniquename</bcf:option>
+ <bcf:option datatype="boolean">singletitle</bcf:option>
+ <bcf:option datatype="boolean">uniquetitle</bcf:option>
+ <bcf:option datatype="boolean">uniquebaretitle</bcf:option>
+ <bcf:option datatype="boolean">uniquework</bcf:option>
+ <bcf:option datatype="boolean">useprefix</bcf:option>
+ <bcf:option datatype="boolean">skipbib</bcf:option>
+ <bcf:option datatype="boolean">skipbiblist</bcf:option>
+ <bcf:option datatype="boolean">skiplab</bcf:option>
+ <bcf:option datatype="boolean">dataonly</bcf:option>
+ <bcf:option datatype="boolean">skiplos</bcf:option>
+ <bcf:option datatype="boolean">labelyear</bcf:option>
+ <bcf:option datatype="xml">labelalphatemplate</bcf:option>
+ <bcf:option datatype="xml">translit</bcf:option>
+ <bcf:option datatype="xml">sortexclusion</bcf:option>
+ <bcf:option datatype="xml">sortinclusion</bcf:option>
+ <bcf:option datatype="xml">labelnamespec</bcf:option>
+ <bcf:option datatype="xml">labeltitlespec</bcf:option>
+ <bcf:option datatype="xml">labeldatespec</bcf:option>
+ <bcf:option datatype="integer">maxnames</bcf:option>
+ <bcf:option datatype="integer">minnames</bcf:option>
+ <bcf:option datatype="integer">maxbibnames</bcf:option>
+ <bcf:option datatype="integer">minbibnames</bcf:option>
+ <bcf:option datatype="integer">maxcitenames</bcf:option>
+ <bcf:option datatype="integer">mincitenames</bcf:option>
+ <bcf:option datatype="integer">maxitems</bcf:option>
+ <bcf:option datatype="integer">minitems</bcf:option>
+ <bcf:option datatype="integer">maxalphanames</bcf:option>
+ <bcf:option datatype="integer">minalphanames</bcf:option>
+ </bcf:optionscope>
+ <bcf:optionscope type="ENTRY">
+ <bcf:option datatype="string">noinherit</bcf:option>
+ <bcf:option datatype="string">nametemplates</bcf:option>
+ <bcf:option datatype="string">labelalphanametemplatename</bcf:option>
+ <bcf:option datatype="string">uniquenametemplatename</bcf:option>
+ <bcf:option datatype="string">sortingnamekeytemplatename</bcf:option>
+ <bcf:option datatype="string">presort</bcf:option>
+ <bcf:option datatype="boolean">useafterword</bcf:option>
+ <bcf:option datatype="boolean">useannotator</bcf:option>
+ <bcf:option datatype="boolean">useauthor</bcf:option>
+ <bcf:option datatype="boolean">usebookauthor</bcf:option>
+ <bcf:option datatype="boolean">usecommentator</bcf:option>
+ <bcf:option datatype="boolean">useeditor</bcf:option>
+ <bcf:option datatype="boolean">useeditora</bcf:option>
+ <bcf:option datatype="boolean">useeditorb</bcf:option>
+ <bcf:option datatype="boolean">useeditorc</bcf:option>
+ <bcf:option datatype="boolean">useforeword</bcf:option>
+ <bcf:option datatype="boolean">useholder</bcf:option>
+ <bcf:option datatype="boolean">useintroduction</bcf:option>
+ <bcf:option datatype="boolean">usenamea</bcf:option>
+ <bcf:option datatype="boolean">usenameb</bcf:option>
+ <bcf:option datatype="boolean">usenamec</bcf:option>
+ <bcf:option datatype="boolean">usetranslator</bcf:option>
+ <bcf:option datatype="boolean">useshortauthor</bcf:option>
+ <bcf:option datatype="boolean">useshorteditor</bcf:option>
+ <bcf:option datatype="boolean">indexing</bcf:option>
+ <bcf:option datatype="boolean">uniquelist</bcf:option>
+ <bcf:option datatype="boolean">uniquename</bcf:option>
+ <bcf:option datatype="boolean">useprefix</bcf:option>
+ <bcf:option datatype="boolean">skipbib</bcf:option>
+ <bcf:option datatype="boolean">skipbiblist</bcf:option>
+ <bcf:option datatype="boolean">skiplab</bcf:option>
+ <bcf:option datatype="boolean">dataonly</bcf:option>
+ <bcf:option datatype="boolean">skiplos</bcf:option>
+ <bcf:option datatype="integer">maxnames</bcf:option>
+ <bcf:option datatype="integer">minnames</bcf:option>
+ <bcf:option datatype="integer">maxbibnames</bcf:option>
+ <bcf:option datatype="integer">minbibnames</bcf:option>
+ <bcf:option datatype="integer">maxcitenames</bcf:option>
+ <bcf:option datatype="integer">mincitenames</bcf:option>
+ <bcf:option datatype="integer">maxitems</bcf:option>
+ <bcf:option datatype="integer">minitems</bcf:option>
+ <bcf:option datatype="integer">maxalphanames</bcf:option>
+ <bcf:option datatype="integer">minalphanames</bcf:option>
+ </bcf:optionscope>
+ <bcf:optionscope type="NAMELIST">
+ <bcf:option datatype="string">nametemplates</bcf:option>
+ <bcf:option datatype="string">sortingnamekeytemplatename</bcf:option>
+ <bcf:option datatype="string">uniquenametemplatename</bcf:option>
+ <bcf:option datatype="string">labelalphanametemplatename</bcf:option>
+ <bcf:option datatype="boolean">useprefix</bcf:option>
+ </bcf:optionscope>
+ <bcf:optionscope type="NAME">
+ <bcf:option datatype="string">nametemplates</bcf:option>
+ <bcf:option datatype="string">sortingnamekeytemplatename</bcf:option>
+ <bcf:option datatype="string">uniquenametemplatename</bcf:option>
+ <bcf:option datatype="string">labelalphanametemplatename</bcf:option>
+ <bcf:option datatype="boolean">useprefix</bcf:option>
+ </bcf:optionscope>
+ <!-- DATAFIELDSETS -->
+ <bcf:datafieldset name="setnames">
+ <bcf:member datatype="name" fieldtype="list"/>
+ </bcf:datafieldset>
+ <bcf:datafieldset name="settitles">
+ <bcf:member field="title"/>
+ <bcf:member field="booktitle"/>
+ <bcf:member field="eventtitle"/>
+ <bcf:member field="issuetitle"/>
+ <bcf:member field="journaltitle"/>
+ <bcf:member field="maintitle"/>
+ <bcf:member field="origtitle"/>
+ </bcf:datafieldset>
+ <!-- SOURCEMAP -->
+ <bcf:sourcemap>
+ <bcf:maps datatype="bibtex" level="driver">
+ <bcf:map>
+ <bcf:map_step map_field_set="day" map_null="1"/>
+ </bcf:map>
+ <bcf:map>
+ <bcf:map_step map_type_source="conference" map_type_target="inproceedings"/>
+ <bcf:map_step map_type_source="electronic" map_type_target="online"/>
+ <bcf:map_step map_type_source="www" map_type_target="online"/>
+ </bcf:map>
+ <bcf:map>
+ <bcf:map_step map_type_source="mastersthesis" map_type_target="thesis" map_final="1"/>
+ <bcf:map_step map_field_set="type" map_field_value="mathesis"/>
+ </bcf:map>
+ <bcf:map>
+ <bcf:map_step map_type_source="phdthesis" map_type_target="thesis" map_final="1"/>
+ <bcf:map_step map_field_set="type" map_field_value="phdthesis"/>
+ </bcf:map>
+ <bcf:map>
+ <bcf:map_step map_type_source="techreport" map_type_target="report" map_final="1"/>
+ <bcf:map_step map_field_set="type" map_field_value="techreport"/>
+ </bcf:map>
+ <bcf:map>
+ <bcf:map_step map_field_source="hyphenation" map_field_target="langid"/>
+ <bcf:map_step map_field_source="address" map_field_target="location"/>
+ <bcf:map_step map_field_source="school" map_field_target="institution"/>
+ <bcf:map_step map_field_source="annote" map_field_target="annotation"/>
+ <bcf:map_step map_field_source="archiveprefix" map_field_target="eprinttype"/>
+ <bcf:map_step map_field_source="journal" map_field_target="journaltitle"/>
+ <bcf:map_step map_field_source="primaryclass" map_field_target="eprintclass"/>
+ <bcf:map_step map_field_source="key" map_field_target="sortkey"/>
+ <bcf:map_step map_field_source="pdf" map_field_target="file"/>
+ </bcf:map>
+ </bcf:maps>
+ </bcf:sourcemap>
+ <!-- LABELALPHA NAME TEMPLATE -->
+ <bcf:labelalphanametemplate name="global">
+ <bcf:namepart order="1" use="1" pre="1" substring_width="1" substring_compound="1">prefix</bcf:namepart>
+ <bcf:namepart order="2">family</bcf:namepart>
+ </bcf:labelalphanametemplate>
+ <!-- LABELALPHA TEMPLATE -->
+ <bcf:labelalphatemplate type="global">
+ <bcf:labelelement order="1">
+ <bcf:labelpart final="1">shorthand</bcf:labelpart>
+ <bcf:labelpart>label</bcf:labelpart>
+ <bcf:labelpart substring_width="3" substring_side="left" ifnames="1">labelname</bcf:labelpart>
+ <bcf:labelpart substring_width="1" substring_side="left">labelname</bcf:labelpart>
+ </bcf:labelelement>
+ <bcf:labelelement order="2">
+ <bcf:labelpart substring_width="2" substring_side="right">year</bcf:labelpart>
+ </bcf:labelelement>
+ </bcf:labelalphatemplate>
+ <!-- EXTRADATE -->
+ <bcf:extradatespec>
+ <bcf:scope>
+ <bcf:field order="1">labelyear</bcf:field>
+ <bcf:field order="2">year</bcf:field>
+ </bcf:scope>
+ </bcf:extradatespec>
+ <!-- INHERITANCE -->
+ <bcf:inheritance>
+ <bcf:defaults inherit_all="true" override_target="false">
+ </bcf:defaults>
+ <bcf:inherit>
+ <bcf:type_pair source="mvbook" target="inbook"/>
+ <bcf:type_pair source="mvbook" target="bookinbook"/>
+ <bcf:type_pair source="mvbook" target="suppbook"/>
+ <bcf:type_pair source="book" target="inbook"/>
+ <bcf:type_pair source="book" target="bookinbook"/>
+ <bcf:type_pair source="book" target="suppbook"/>
+ <bcf:field source="author" target="author"/>
+ <bcf:field source="author" target="bookauthor"/>
+ </bcf:inherit>
+ <bcf:inherit>
+ <bcf:type_pair source="mvbook" target="book"/>
+ <bcf:type_pair source="mvbook" target="inbook"/>
+ <bcf:type_pair source="mvbook" target="bookinbook"/>
+ <bcf:type_pair source="mvbook" target="suppbook"/>
+ <bcf:field source="title" target="maintitle"/>
+ <bcf:field source="subtitle" target="mainsubtitle"/>
+ <bcf:field source="titleaddon" target="maintitleaddon"/>
+ <bcf:field source="shorttitle" skip="true"/>
+ <bcf:field source="sorttitle" skip="true"/>
+ <bcf:field source="indextitle" skip="true"/>
+ <bcf:field source="indexsorttitle" skip="true"/>
+ </bcf:inherit>
+ <bcf:inherit>
+ <bcf:type_pair source="mvcollection" target="collection"/>
+ <bcf:type_pair source="mvcollection" target="reference"/>
+ <bcf:type_pair source="mvcollection" target="incollection"/>
+ <bcf:type_pair source="mvcollection" target="inreference"/>
+ <bcf:type_pair source="mvcollection" target="suppcollection"/>
+ <bcf:type_pair source="mvreference" target="collection"/>
+ <bcf:type_pair source="mvreference" target="reference"/>
+ <bcf:type_pair source="mvreference" target="incollection"/>
+ <bcf:type_pair source="mvreference" target="inreference"/>
+ <bcf:type_pair source="mvreference" target="suppcollection"/>
+ <bcf:field source="title" target="maintitle"/>
+ <bcf:field source="subtitle" target="mainsubtitle"/>
+ <bcf:field source="titleaddon" target="maintitleaddon"/>
+ <bcf:field source="shorttitle" skip="true"/>
+ <bcf:field source="sorttitle" skip="true"/>
+ <bcf:field source="indextitle" skip="true"/>
+ <bcf:field source="indexsorttitle" skip="true"/>
+ </bcf:inherit>
+ <bcf:inherit>
+ <bcf:type_pair source="mvproceedings" target="proceedings"/>
+ <bcf:type_pair source="mvproceedings" target="inproceedings"/>
+ <bcf:field source="title" target="maintitle"/>
+ <bcf:field source="subtitle" target="mainsubtitle"/>
+ <bcf:field source="titleaddon" target="maintitleaddon"/>
+ <bcf:field source="shorttitle" skip="true"/>
+ <bcf:field source="sorttitle" skip="true"/>
+ <bcf:field source="indextitle" skip="true"/>
+ <bcf:field source="indexsorttitle" skip="true"/>
+ </bcf:inherit>
+ <bcf:inherit>
+ <bcf:type_pair source="book" target="inbook"/>
+ <bcf:type_pair source="book" target="bookinbook"/>
+ <bcf:type_pair source="book" target="suppbook"/>
+ <bcf:field source="title" target="booktitle"/>
+ <bcf:field source="subtitle" target="booksubtitle"/>
+ <bcf:field source="titleaddon" target="booktitleaddon"/>
+ <bcf:field source="shorttitle" skip="true"/>
+ <bcf:field source="sorttitle" skip="true"/>
+ <bcf:field source="indextitle" skip="true"/>
+ <bcf:field source="indexsorttitle" skip="true"/>
+ </bcf:inherit>
+ <bcf:inherit>
+ <bcf:type_pair source="collection" target="incollection"/>
+ <bcf:type_pair source="collection" target="inreference"/>
+ <bcf:type_pair source="collection" target="suppcollection"/>
+ <bcf:type_pair source="reference" target="incollection"/>
+ <bcf:type_pair source="reference" target="inreference"/>
+ <bcf:type_pair source="reference" target="suppcollection"/>
+ <bcf:field source="title" target="booktitle"/>
+ <bcf:field source="subtitle" target="booksubtitle"/>
+ <bcf:field source="titleaddon" target="booktitleaddon"/>
+ <bcf:field source="shorttitle" skip="true"/>
+ <bcf:field source="sorttitle" skip="true"/>
+ <bcf:field source="indextitle" skip="true"/>
+ <bcf:field source="indexsorttitle" skip="true"/>
+ </bcf:inherit>
+ <bcf:inherit>
+ <bcf:type_pair source="proceedings" target="inproceedings"/>
+ <bcf:field source="title" target="booktitle"/>
+ <bcf:field source="subtitle" target="booksubtitle"/>
+ <bcf:field source="titleaddon" target="booktitleaddon"/>
+ <bcf:field source="shorttitle" skip="true"/>
+ <bcf:field source="sorttitle" skip="true"/>
+ <bcf:field source="indextitle" skip="true"/>
+ <bcf:field source="indexsorttitle" skip="true"/>
+ </bcf:inherit>
+ <bcf:inherit>
+ <bcf:type_pair source="periodical" target="article"/>
+ <bcf:type_pair source="periodical" target="suppperiodical"/>
+ <bcf:field source="title" target="journaltitle"/>
+ <bcf:field source="subtitle" target="journalsubtitle"/>
+ <bcf:field source="shorttitle" skip="true"/>
+ <bcf:field source="sorttitle" skip="true"/>
+ <bcf:field source="indextitle" skip="true"/>
+ <bcf:field source="indexsorttitle" skip="true"/>
+ </bcf:inherit>
+ <bcf:inherit>
+ <bcf:type_pair source="*" target="*"/>
+ <bcf:field source="ids" skip="true"/>
+ <bcf:field source="crossref" skip="true"/>
+ <bcf:field source="xref" skip="true"/>
+ <bcf:field source="entryset" skip="true"/>
+ <bcf:field source="entrysubtype" skip="true"/>
+ <bcf:field source="execute" skip="true"/>
+ <bcf:field source="label" skip="true"/>
+ <bcf:field source="options" skip="true"/>
+ <bcf:field source="presort" skip="true"/>
+ <bcf:field source="related" skip="true"/>
+ <bcf:field source="relatedoptions" skip="true"/>
+ <bcf:field source="relatedstring" skip="true"/>
+ <bcf:field source="relatedtype" skip="true"/>
+ <bcf:field source="shorthand" skip="true"/>
+ <bcf:field source="shorthandintro" skip="true"/>
+ <bcf:field source="sortkey" skip="true"/>
+ </bcf:inherit>
+ </bcf:inheritance>
+ <!-- UNIQUENAME TEMPLATES -->
+ <bcf:uniquenametemplate name="global">
+ <bcf:namepart order="1" use="1" base="1">prefix</bcf:namepart>
+ <bcf:namepart order="2" base="1">family</bcf:namepart>
+ <bcf:namepart order="3">given</bcf:namepart>
+ </bcf:uniquenametemplate>
+ <!-- SORTING NAME KEY TEMPLATES -->
+ <bcf:sortingnamekeytemplate name="global">
+ <bcf:keypart order="1">
+ <bcf:part type="namepart" order="1" use="1">prefix</bcf:part>
+ </bcf:keypart>
+ <bcf:keypart order="2">
+ <bcf:part type="namepart" order="1">family</bcf:part>
+ </bcf:keypart>
+ <bcf:keypart order="3">
+ <bcf:part type="namepart" order="1">given</bcf:part>
+ </bcf:keypart>
+ <bcf:keypart order="4">
+ <bcf:part type="namepart" order="1">suffix</bcf:part>
+ </bcf:keypart>
+ <bcf:keypart order="5">
+ <bcf:part type="namepart" order="1" use="0">prefix</bcf:part>
+ </bcf:keypart>
+ </bcf:sortingnamekeytemplate>
+ <bcf:presort>mm</bcf:presort>
+ <!-- DATA MODEL -->
+ <bcf:datamodel>
+ <bcf:constants>
+ <bcf:constant type="list" name="gender">sf,sm,sn,pf,pm,pn,pp</bcf:constant>
+ <bcf:constant type="list" name="nameparts">family,given,prefix,suffix</bcf:constant>
+ <bcf:constant type="list" name="optiondatatypes">boolean,integer,string,xml</bcf:constant>
+ </bcf:constants>
+ <bcf:entrytypes>
+ <bcf:entrytype>article</bcf:entrytype>
+ <bcf:entrytype>artwork</bcf:entrytype>
+ <bcf:entrytype>audio</bcf:entrytype>
+ <bcf:entrytype>bibnote</bcf:entrytype>
+ <bcf:entrytype>book</bcf:entrytype>
+ <bcf:entrytype>bookinbook</bcf:entrytype>
+ <bcf:entrytype>booklet</bcf:entrytype>
+ <bcf:entrytype>collection</bcf:entrytype>
+ <bcf:entrytype>commentary</bcf:entrytype>
+ <bcf:entrytype>customa</bcf:entrytype>
+ <bcf:entrytype>customb</bcf:entrytype>
+ <bcf:entrytype>customc</bcf:entrytype>
+ <bcf:entrytype>customd</bcf:entrytype>
+ <bcf:entrytype>custome</bcf:entrytype>
+ <bcf:entrytype>customf</bcf:entrytype>
+ <bcf:entrytype>inbook</bcf:entrytype>
+ <bcf:entrytype>incollection</bcf:entrytype>
+ <bcf:entrytype>inproceedings</bcf:entrytype>
+ <bcf:entrytype>inreference</bcf:entrytype>
+ <bcf:entrytype>image</bcf:entrytype>
+ <bcf:entrytype>jurisdiction</bcf:entrytype>
+ <bcf:entrytype>legal</bcf:entrytype>
+ <bcf:entrytype>legislation</bcf:entrytype>
+ <bcf:entrytype>letter</bcf:entrytype>
+ <bcf:entrytype>manual</bcf:entrytype>
+ <bcf:entrytype>misc</bcf:entrytype>
+ <bcf:entrytype>movie</bcf:entrytype>
+ <bcf:entrytype>music</bcf:entrytype>
+ <bcf:entrytype>mvcollection</bcf:entrytype>
+ <bcf:entrytype>mvreference</bcf:entrytype>
+ <bcf:entrytype>mvproceedings</bcf:entrytype>
+ <bcf:entrytype>mvbook</bcf:entrytype>
+ <bcf:entrytype>online</bcf:entrytype>
+ <bcf:entrytype>patent</bcf:entrytype>
+ <bcf:entrytype>performance</bcf:entrytype>
+ <bcf:entrytype>periodical</bcf:entrytype>
+ <bcf:entrytype>proceedings</bcf:entrytype>
+ <bcf:entrytype>reference</bcf:entrytype>
+ <bcf:entrytype>report</bcf:entrytype>
+ <bcf:entrytype>review</bcf:entrytype>
+ <bcf:entrytype>set</bcf:entrytype>
+ <bcf:entrytype>software</bcf:entrytype>
+ <bcf:entrytype>standard</bcf:entrytype>
+ <bcf:entrytype>suppbook</bcf:entrytype>
+ <bcf:entrytype>suppcollection</bcf:entrytype>
+ <bcf:entrytype>suppperiodical</bcf:entrytype>
+ <bcf:entrytype>thesis</bcf:entrytype>
+ <bcf:entrytype>unpublished</bcf:entrytype>
+ <bcf:entrytype>video</bcf:entrytype>
+ <bcf:entrytype skip_output="true">xdata</bcf:entrytype>
+ </bcf:entrytypes>
+ <bcf:fields>
+ <bcf:field fieldtype="field" datatype="integer">number</bcf:field>
+ <bcf:field fieldtype="field" datatype="integer">volume</bcf:field>
+ <bcf:field fieldtype="field" datatype="integer">volumes</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">abstract</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">addendum</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">annotation</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">booksubtitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">booktitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">booktitleaddon</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">chapter</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">edition</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">eid</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">entrysubtype</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">eprintclass</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">eprinttype</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">eventtitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">eventtitleaddon</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">gender</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">howpublished</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">indexsorttitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">indextitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">isan</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">isbn</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">ismn</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">isrn</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">issn</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">issue</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">issuesubtitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">issuetitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">iswc</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">journalsubtitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">journaltitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">label</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">langid</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">langidopts</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">library</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">mainsubtitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">maintitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">maintitleaddon</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">nameaddon</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">note</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">origtitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">pagetotal</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">part</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">relatedstring</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">relatedtype</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">reprinttitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">series</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">shorthandintro</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">subtitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">title</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">titleaddon</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">usera</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">userb</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">userc</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">userd</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">usere</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">userf</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">venue</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal">version</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" label="true">shorthand</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" label="true">shortjournal</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" label="true">shortseries</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" label="true">shorttitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" skip_output="true">sortyear</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" skip_output="true">sorttitle</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" skip_output="true">sortshorthand</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" skip_output="true">sortkey</bcf:field>
+ <bcf:field fieldtype="field" datatype="literal" skip_output="true">presort</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">institution</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">lista</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">listb</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">listc</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">listd</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">liste</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">listf</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">location</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">organization</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">origlocation</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">origpublisher</bcf:field>
+ <bcf:field fieldtype="list" datatype="literal">publisher</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">afterword</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">annotator</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">author</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">bookauthor</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">commentator</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">editor</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">editora</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">editorb</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">editorc</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">foreword</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">holder</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">introduction</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">namea</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">nameb</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">namec</bcf:field>
+ <bcf:field fieldtype="list" datatype="name">translator</bcf:field>
+ <bcf:field fieldtype="list" datatype="name" label="true">shortauthor</bcf:field>
+ <bcf:field fieldtype="list" datatype="name" label="true">shorteditor</bcf:field>
+ <bcf:field fieldtype="list" datatype="name" skip_output="true">sortname</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">authortype</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">editoratype</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">editorbtype</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">editorctype</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">editortype</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">bookpagination</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">nameatype</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">namebtype</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">namectype</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">pagination</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">pubstate</bcf:field>
+ <bcf:field fieldtype="field" datatype="key">type</bcf:field>
+ <bcf:field fieldtype="list" datatype="key">language</bcf:field>
+ <bcf:field fieldtype="list" datatype="key">origlanguage</bcf:field>
+ <bcf:field fieldtype="field" datatype="entrykey">crossref</bcf:field>
+ <bcf:field fieldtype="field" datatype="entrykey">xref</bcf:field>
+ <bcf:field fieldtype="field" datatype="date" skip_output="true">date</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart" nullok="true">endyear</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart" nullok="true">year</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">month</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">day</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">hour</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">minute</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">second</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">timezone</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">season</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">endmonth</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">endday</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">endhour</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">endminute</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">endsecond</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">endtimezone</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">endseason</bcf:field>
+ <bcf:field fieldtype="field" datatype="date" skip_output="true">eventdate</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart" nullok="true">eventendyear</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart" nullok="true">eventyear</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventmonth</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventday</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventhour</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventminute</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventsecond</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventtimezone</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventseason</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventendmonth</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventendday</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventendhour</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventendminute</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventendsecond</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventendtimezone</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">eventendseason</bcf:field>
+ <bcf:field fieldtype="field" datatype="date" skip_output="true">origdate</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart" nullok="true">origendyear</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart" nullok="true">origyear</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origmonth</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origday</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">orighour</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origminute</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origsecond</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origtimezone</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origseason</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origendmonth</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origendday</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origendhour</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origendminute</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origendsecond</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origendtimezone</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">origendseason</bcf:field>
+ <bcf:field fieldtype="field" datatype="date" skip_output="true">urldate</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart" nullok="true">urlendyear</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart" nullok="true">urlyear</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlmonth</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlday</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlhour</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlminute</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlsecond</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urltimezone</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlseason</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlendmonth</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlendday</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlendhour</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlendminute</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlendsecond</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlendtimezone</bcf:field>
+ <bcf:field fieldtype="field" datatype="datepart">urlendseason</bcf:field>
+ <bcf:field fieldtype="field" datatype="verbatim">doi</bcf:field>
+ <bcf:field fieldtype="field" datatype="verbatim">eprint</bcf:field>
+ <bcf:field fieldtype="field" datatype="verbatim">file</bcf:field>
+ <bcf:field fieldtype="field" datatype="verbatim">verba</bcf:field>
+ <bcf:field fieldtype="field" datatype="verbatim">verbb</bcf:field>
+ <bcf:field fieldtype="field" datatype="verbatim">verbc</bcf:field>
+ <bcf:field fieldtype="field" datatype="uri">url</bcf:field>
+ <bcf:field fieldtype="field" format="xsv" datatype="entrykey" skip_output="true">xdata</bcf:field>
+ <bcf:field fieldtype="field" format="xsv" datatype="entrykey" skip_output="true">ids</bcf:field>
+ <bcf:field fieldtype="field" format="xsv" datatype="entrykey" skip_output="true">entryset</bcf:field>
+ <bcf:field fieldtype="field" format="xsv" datatype="entrykey">related</bcf:field>
+ <bcf:field fieldtype="field" format="xsv" datatype="keyword">keywords</bcf:field>
+ <bcf:field fieldtype="field" format="xsv" datatype="option" skip_output="true">options</bcf:field>
+ <bcf:field fieldtype="field" format="xsv" datatype="option" skip_output="true">relatedoptions</bcf:field>
+ <bcf:field fieldtype="field" datatype="range">pages</bcf:field>
+ <bcf:field fieldtype="field" datatype="code">execute</bcf:field>
+ </bcf:fields>
+ <bcf:entryfields>
+ <bcf:field>abstract</bcf:field>
+ <bcf:field>annotation</bcf:field>
+ <bcf:field>authortype</bcf:field>
+ <bcf:field>bookpagination</bcf:field>
+ <bcf:field>crossref</bcf:field>
+ <bcf:field>day</bcf:field>
+ <bcf:field>endday</bcf:field>
+ <bcf:field>endhour</bcf:field>
+ <bcf:field>endminute</bcf:field>
+ <bcf:field>endmonth</bcf:field>
+ <bcf:field>endseason</bcf:field>
+ <bcf:field>endsecond</bcf:field>
+ <bcf:field>endtimezone</bcf:field>
+ <bcf:field>endyear</bcf:field>
+ <bcf:field>entryset</bcf:field>
+ <bcf:field>entrysubtype</bcf:field>
+ <bcf:field>execute</bcf:field>
+ <bcf:field>file</bcf:field>
+ <bcf:field>gender</bcf:field>
+ <bcf:field>hour</bcf:field>
+ <bcf:field>ids</bcf:field>
+ <bcf:field>indextitle</bcf:field>
+ <bcf:field>indexsorttitle</bcf:field>
+ <bcf:field>isan</bcf:field>
+ <bcf:field>ismn</bcf:field>
+ <bcf:field>iswc</bcf:field>
+ <bcf:field>keywords</bcf:field>
+ <bcf:field>label</bcf:field>
+ <bcf:field>langid</bcf:field>
+ <bcf:field>langidopts</bcf:field>
+ <bcf:field>library</bcf:field>
+ <bcf:field>lista</bcf:field>
+ <bcf:field>listb</bcf:field>
+ <bcf:field>listc</bcf:field>
+ <bcf:field>listd</bcf:field>
+ <bcf:field>liste</bcf:field>
+ <bcf:field>listf</bcf:field>
+ <bcf:field>minute</bcf:field>
+ <bcf:field>month</bcf:field>
+ <bcf:field>nameaddon</bcf:field>
+ <bcf:field>options</bcf:field>
+ <bcf:field>origday</bcf:field>
+ <bcf:field>origendday</bcf:field>
+ <bcf:field>origendhour</bcf:field>
+ <bcf:field>origendminute</bcf:field>
+ <bcf:field>origendmonth</bcf:field>
+ <bcf:field>origendseason</bcf:field>
+ <bcf:field>origendsecond</bcf:field>
+ <bcf:field>origendtimezone</bcf:field>
+ <bcf:field>origendyear</bcf:field>
+ <bcf:field>orighour</bcf:field>
+ <bcf:field>origminute</bcf:field>
+ <bcf:field>origmonth</bcf:field>
+ <bcf:field>origseason</bcf:field>
+ <bcf:field>origsecond</bcf:field>
+ <bcf:field>origtimezone</bcf:field>
+ <bcf:field>origyear</bcf:field>
+ <bcf:field>origlocation</bcf:field>
+ <bcf:field>origpublisher</bcf:field>
+ <bcf:field>origtitle</bcf:field>
+ <bcf:field>pagination</bcf:field>
+ <bcf:field>presort</bcf:field>
+ <bcf:field>related</bcf:field>
+ <bcf:field>relatedoptions</bcf:field>
+ <bcf:field>relatedstring</bcf:field>
+ <bcf:field>relatedtype</bcf:field>
+ <bcf:field>season</bcf:field>
+ <bcf:field>second</bcf:field>
+ <bcf:field>shortauthor</bcf:field>
+ <bcf:field>shorteditor</bcf:field>
+ <bcf:field>shorthand</bcf:field>
+ <bcf:field>shorthandintro</bcf:field>
+ <bcf:field>shortjournal</bcf:field>
+ <bcf:field>shortseries</bcf:field>
+ <bcf:field>shorttitle</bcf:field>
+ <bcf:field>sortkey</bcf:field>
+ <bcf:field>sortname</bcf:field>
+ <bcf:field>sortshorthand</bcf:field>
+ <bcf:field>sorttitle</bcf:field>
+ <bcf:field>sortyear</bcf:field>
+ <bcf:field>timezone</bcf:field>
+ <bcf:field>url</bcf:field>
+ <bcf:field>urlday</bcf:field>
+ <bcf:field>urlendday</bcf:field>
+ <bcf:field>urlendhour</bcf:field>
+ <bcf:field>urlendminute</bcf:field>
+ <bcf:field>urlendmonth</bcf:field>
+ <bcf:field>urlendsecond</bcf:field>
+ <bcf:field>urlendtimezone</bcf:field>
+ <bcf:field>urlendyear</bcf:field>
+ <bcf:field>urlhour</bcf:field>
+ <bcf:field>urlminute</bcf:field>
+ <bcf:field>urlmonth</bcf:field>
+ <bcf:field>urlsecond</bcf:field>
+ <bcf:field>urltimezone</bcf:field>
+ <bcf:field>urlyear</bcf:field>
+ <bcf:field>usera</bcf:field>
+ <bcf:field>userb</bcf:field>
+ <bcf:field>userc</bcf:field>
+ <bcf:field>userd</bcf:field>
+ <bcf:field>usere</bcf:field>
+ <bcf:field>userf</bcf:field>
+ <bcf:field>verba</bcf:field>
+ <bcf:field>verbb</bcf:field>
+ <bcf:field>verbc</bcf:field>
+ <bcf:field>xdata</bcf:field>
+ <bcf:field>xref</bcf:field>
+ <bcf:field>year</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>set</bcf:entrytype>
+ <bcf:field>entryset</bcf:field>
+ <bcf:field>crossref</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>article</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>annotator</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>commentator</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editora</bcf:field>
+ <bcf:field>editorb</bcf:field>
+ <bcf:field>editorc</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>editoratype</bcf:field>
+ <bcf:field>editorbtype</bcf:field>
+ <bcf:field>editorctype</bcf:field>
+ <bcf:field>eid</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>issn</bcf:field>
+ <bcf:field>issue</bcf:field>
+ <bcf:field>issuetitle</bcf:field>
+ <bcf:field>issuesubtitle</bcf:field>
+ <bcf:field>journalsubtitle</bcf:field>
+ <bcf:field>journaltitle</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>origlanguage</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>translator</bcf:field>
+ <bcf:field>version</bcf:field>
+ <bcf:field>volume</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>bibnote</bcf:entrytype>
+ <bcf:field>note</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>book</bcf:entrytype>
+ <bcf:field>author</bcf:field>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>afterword</bcf:field>
+ <bcf:field>annotator</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>commentator</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>edition</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editora</bcf:field>
+ <bcf:field>editorb</bcf:field>
+ <bcf:field>editorc</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>editoratype</bcf:field>
+ <bcf:field>editorbtype</bcf:field>
+ <bcf:field>editorctype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>foreword</bcf:field>
+ <bcf:field>introduction</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>maintitle</bcf:field>
+ <bcf:field>maintitleaddon</bcf:field>
+ <bcf:field>mainsubtitle</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>origlanguage</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>part</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>translator</bcf:field>
+ <bcf:field>volume</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>mvbook</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>afterword</bcf:field>
+ <bcf:field>annotator</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>commentator</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>edition</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editora</bcf:field>
+ <bcf:field>editorb</bcf:field>
+ <bcf:field>editorc</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>editoratype</bcf:field>
+ <bcf:field>editorbtype</bcf:field>
+ <bcf:field>editorctype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>foreword</bcf:field>
+ <bcf:field>introduction</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>origlanguage</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>translator</bcf:field>
+ <bcf:field>volume</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>inbook</bcf:entrytype>
+ <bcf:entrytype>bookinbook</bcf:entrytype>
+ <bcf:entrytype>suppbook</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>afterword</bcf:field>
+ <bcf:field>annotator</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>booktitle</bcf:field>
+ <bcf:field>bookauthor</bcf:field>
+ <bcf:field>booksubtitle</bcf:field>
+ <bcf:field>booktitleaddon</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>commentator</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>edition</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editora</bcf:field>
+ <bcf:field>editorb</bcf:field>
+ <bcf:field>editorc</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>editoratype</bcf:field>
+ <bcf:field>editorbtype</bcf:field>
+ <bcf:field>editorctype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>foreword</bcf:field>
+ <bcf:field>introduction</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>mainsubtitle</bcf:field>
+ <bcf:field>maintitle</bcf:field>
+ <bcf:field>maintitleaddon</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>origlanguage</bcf:field>
+ <bcf:field>part</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>translator</bcf:field>
+ <bcf:field>volume</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>booklet</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>howpublished</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>type</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>collection</bcf:entrytype>
+ <bcf:entrytype>reference</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>afterword</bcf:field>
+ <bcf:field>annotator</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>commentator</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>edition</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editora</bcf:field>
+ <bcf:field>editorb</bcf:field>
+ <bcf:field>editorc</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>editoratype</bcf:field>
+ <bcf:field>editorbtype</bcf:field>
+ <bcf:field>editorctype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>foreword</bcf:field>
+ <bcf:field>introduction</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>mainsubtitle</bcf:field>
+ <bcf:field>maintitle</bcf:field>
+ <bcf:field>maintitleaddon</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>origlanguage</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>part</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>translator</bcf:field>
+ <bcf:field>volume</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>mvcollection</bcf:entrytype>
+ <bcf:entrytype>mvreference</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>afterword</bcf:field>
+ <bcf:field>annotator</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>commentator</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>edition</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editora</bcf:field>
+ <bcf:field>editorb</bcf:field>
+ <bcf:field>editorc</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>editoratype</bcf:field>
+ <bcf:field>editorbtype</bcf:field>
+ <bcf:field>editorctype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>foreword</bcf:field>
+ <bcf:field>introduction</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>origlanguage</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>translator</bcf:field>
+ <bcf:field>volume</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>incollection</bcf:entrytype>
+ <bcf:entrytype>suppcollection</bcf:entrytype>
+ <bcf:entrytype>inreference</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>afterword</bcf:field>
+ <bcf:field>annotator</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>booksubtitle</bcf:field>
+ <bcf:field>booktitle</bcf:field>
+ <bcf:field>booktitleaddon</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>commentator</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>edition</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editora</bcf:field>
+ <bcf:field>editorb</bcf:field>
+ <bcf:field>editorc</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>editoratype</bcf:field>
+ <bcf:field>editorbtype</bcf:field>
+ <bcf:field>editorctype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>foreword</bcf:field>
+ <bcf:field>introduction</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>mainsubtitle</bcf:field>
+ <bcf:field>maintitle</bcf:field>
+ <bcf:field>maintitleaddon</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>origlanguage</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>part</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>translator</bcf:field>
+ <bcf:field>volume</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>manual</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>edition</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>organization</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>type</bcf:field>
+ <bcf:field>version</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>misc</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>howpublished</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>organization</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>type</bcf:field>
+ <bcf:field>version</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>online</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>organization</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>version</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>patent</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>holder</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>type</bcf:field>
+ <bcf:field>version</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>periodical</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editora</bcf:field>
+ <bcf:field>editorb</bcf:field>
+ <bcf:field>editorc</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>editoratype</bcf:field>
+ <bcf:field>editorbtype</bcf:field>
+ <bcf:field>editorctype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>issn</bcf:field>
+ <bcf:field>issue</bcf:field>
+ <bcf:field>issuesubtitle</bcf:field>
+ <bcf:field>issuetitle</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>season</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>volume</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>mvproceedings</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>eventday</bcf:field>
+ <bcf:field>eventendday</bcf:field>
+ <bcf:field>eventendmonth</bcf:field>
+ <bcf:field>eventendyear</bcf:field>
+ <bcf:field>eventmonth</bcf:field>
+ <bcf:field>eventyear</bcf:field>
+ <bcf:field>eventtitle</bcf:field>
+ <bcf:field>eventtitleaddon</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>organization</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>venue</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>proceedings</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>eventday</bcf:field>
+ <bcf:field>eventendday</bcf:field>
+ <bcf:field>eventendmonth</bcf:field>
+ <bcf:field>eventendyear</bcf:field>
+ <bcf:field>eventmonth</bcf:field>
+ <bcf:field>eventyear</bcf:field>
+ <bcf:field>eventtitle</bcf:field>
+ <bcf:field>eventtitleaddon</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>mainsubtitle</bcf:field>
+ <bcf:field>maintitle</bcf:field>
+ <bcf:field>maintitleaddon</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>organization</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>part</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>venue</bcf:field>
+ <bcf:field>volume</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>inproceedings</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>booksubtitle</bcf:field>
+ <bcf:field>booktitle</bcf:field>
+ <bcf:field>booktitleaddon</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>editortype</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>eventday</bcf:field>
+ <bcf:field>eventendday</bcf:field>
+ <bcf:field>eventendmonth</bcf:field>
+ <bcf:field>eventendyear</bcf:field>
+ <bcf:field>eventmonth</bcf:field>
+ <bcf:field>eventyear</bcf:field>
+ <bcf:field>eventtitle</bcf:field>
+ <bcf:field>eventtitleaddon</bcf:field>
+ <bcf:field>isbn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>mainsubtitle</bcf:field>
+ <bcf:field>maintitle</bcf:field>
+ <bcf:field>maintitleaddon</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>organization</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>part</bcf:field>
+ <bcf:field>publisher</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>series</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>venue</bcf:field>
+ <bcf:field>volume</bcf:field>
+ <bcf:field>volumes</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>report</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>institution</bcf:field>
+ <bcf:field>isrn</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>number</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>type</bcf:field>
+ <bcf:field>version</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>thesis</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>chapter</bcf:field>
+ <bcf:field>doi</bcf:field>
+ <bcf:field>eprint</bcf:field>
+ <bcf:field>eprintclass</bcf:field>
+ <bcf:field>eprinttype</bcf:field>
+ <bcf:field>institution</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>pages</bcf:field>
+ <bcf:field>pagetotal</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ <bcf:field>type</bcf:field>
+ </bcf:entryfields>
+ <bcf:entryfields>
+ <bcf:entrytype>unpublished</bcf:entrytype>
+ <bcf:field>addendum</bcf:field>
+ <bcf:field>author</bcf:field>
+ <bcf:field>howpublished</bcf:field>
+ <bcf:field>language</bcf:field>
+ <bcf:field>location</bcf:field>
+ <bcf:field>note</bcf:field>
+ <bcf:field>pubstate</bcf:field>
+ <bcf:field>subtitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>titleaddon</bcf:field>
+ </bcf:entryfields>
+ <bcf:constraints>
+ <bcf:entrytype>article</bcf:entrytype>
+ <bcf:entrytype>book</bcf:entrytype>
+ <bcf:entrytype>inbook</bcf:entrytype>
+ <bcf:entrytype>bookinbook</bcf:entrytype>
+ <bcf:entrytype>suppbook</bcf:entrytype>
+ <bcf:entrytype>booklet</bcf:entrytype>
+ <bcf:entrytype>collection</bcf:entrytype>
+ <bcf:entrytype>incollection</bcf:entrytype>
+ <bcf:entrytype>suppcollection</bcf:entrytype>
+ <bcf:entrytype>manual</bcf:entrytype>
+ <bcf:entrytype>misc</bcf:entrytype>
+ <bcf:entrytype>mvbook</bcf:entrytype>
+ <bcf:entrytype>mvcollection</bcf:entrytype>
+ <bcf:entrytype>online</bcf:entrytype>
+ <bcf:entrytype>patent</bcf:entrytype>
+ <bcf:entrytype>periodical</bcf:entrytype>
+ <bcf:entrytype>suppperiodical</bcf:entrytype>
+ <bcf:entrytype>proceedings</bcf:entrytype>
+ <bcf:entrytype>inproceedings</bcf:entrytype>
+ <bcf:entrytype>reference</bcf:entrytype>
+ <bcf:entrytype>inreference</bcf:entrytype>
+ <bcf:entrytype>report</bcf:entrytype>
+ <bcf:entrytype>set</bcf:entrytype>
+ <bcf:entrytype>thesis</bcf:entrytype>
+ <bcf:entrytype>unpublished</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:fieldxor>
+ <bcf:field>date</bcf:field>
+ <bcf:field>year</bcf:field>
+ </bcf:fieldxor>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>set</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>entryset</bcf:field>
+ <bcf:field>crossref</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>article</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>journaltitle</bcf:field>
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>book</bcf:entrytype>
+ <bcf:entrytype>mvbook</bcf:entrytype>
+ <bcf:entrytype>mvcollection</bcf:entrytype>
+ <bcf:entrytype>mvreference</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>inbook</bcf:entrytype>
+ <bcf:entrytype>bookinbook</bcf:entrytype>
+ <bcf:entrytype>suppbook</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>booktitle</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>booklet</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:fieldor>
+ <bcf:field>author</bcf:field>
+ <bcf:field>editor</bcf:field>
+ </bcf:fieldor>
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>collection</bcf:entrytype>
+ <bcf:entrytype>reference</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>editor</bcf:field>
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>incollection</bcf:entrytype>
+ <bcf:entrytype>suppcollection</bcf:entrytype>
+ <bcf:entrytype>inreference</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>editor</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>booktitle</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>manual</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>misc</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>online</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>title</bcf:field>
+ <bcf:field>url</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>patent</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>number</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>periodical</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>editor</bcf:field>
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>proceedings</bcf:entrytype>
+ <bcf:entrytype>mvproceedings</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>editor</bcf:field>
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>inproceedings</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>booktitle</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>report</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>type</bcf:field>
+ <bcf:field>institution</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>thesis</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>title</bcf:field>
+ <bcf:field>type</bcf:field>
+ <bcf:field>institution</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:entrytype>unpublished</bcf:entrytype>
+ <bcf:constraint type="mandatory">
+ <bcf:field>author</bcf:field>
+ <bcf:field>title</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ <bcf:constraints>
+ <bcf:constraint type="data" datatype="isbn">
+ <bcf:field>isbn</bcf:field>
+ </bcf:constraint>
+ <bcf:constraint type="data" datatype="issn">
+ <bcf:field>issn</bcf:field>
+ </bcf:constraint>
+ <bcf:constraint type="data" datatype="ismn">
+ <bcf:field>ismn</bcf:field>
+ </bcf:constraint>
+ <bcf:constraint type="data" datatype="date">
+ <bcf:field>date</bcf:field>
+ <bcf:field>eventdate</bcf:field>
+ <bcf:field>origdate</bcf:field>
+ <bcf:field>urldate</bcf:field>
+ </bcf:constraint>
+ <bcf:constraint type="data" datatype="pattern" pattern="(?:sf|sm|sn|pf|pm|pn|pp)">
+ <bcf:field>gender</bcf:field>
+ </bcf:constraint>
+ </bcf:constraints>
+ </bcf:datamodel>
+ <!-- CITATION DATA -->
+ <!-- SECTION 0 -->
+ <bcf:bibdata section="0">
+ </bcf:bibdata>
+ <bcf:section number="0">
+ <bcf:citekey order="1">sp800-145</bcf:citekey>
+ <bcf:citekey order="2">Zhang2010</bcf:citekey>
+ <bcf:citekey order="3">redhat-virtualization</bcf:citekey>
+ <bcf:citekey order="4">vmware-virtualization</bcf:citekey>
+ <bcf:citekey order="5">redhat-virtualization</bcf:citekey>
+ <bcf:citekey order="6">oracle-hypervisors</bcf:citekey>
+ <bcf:citekey order="7">redhat-kvm</bcf:citekey>
+ <bcf:citekey order="8">docker-containers</bcf:citekey>
+ <bcf:citekey order="9">sp800-190</bcf:citekey>
+ <bcf:citekey order="10">802.1Q</bcf:citekey>
+ <bcf:citekey order="11">openstack-basic-networking</bcf:citekey>
+ <bcf:citekey order="12">rfc7348</bcf:citekey>
+ <bcf:citekey order="13">openstack-networking-concepts</bcf:citekey>
+ <bcf:citekey order="14">openstack-history</bcf:citekey>
+ <bcf:citekey order="15">openstack-software</bcf:citekey>
+ <bcf:citekey order="0">*</bcf:citekey>
+ </bcf:section>
+ <!-- SORTING TEMPLATES -->
+ <bcf:sortingtemplate name="nty">
+ <bcf:sort order="1">
+ <bcf:sortitem order="1">presort</bcf:sortitem>
+ </bcf:sort>
+ <bcf:sort order="2" final="1">
+ <bcf:sortitem order="1">sortkey</bcf:sortitem>
+ </bcf:sort>
+ <bcf:sort order="3">
+ <bcf:sortitem order="1">sortname</bcf:sortitem>
+ <bcf:sortitem order="2">author</bcf:sortitem>
+ <bcf:sortitem order="3">editor</bcf:sortitem>
+ <bcf:sortitem order="4">translator</bcf:sortitem>
+ <bcf:sortitem order="5">sorttitle</bcf:sortitem>
+ <bcf:sortitem order="6">title</bcf:sortitem>
+ </bcf:sort>
+ <bcf:sort order="4">
+ <bcf:sortitem order="1">sorttitle</bcf:sortitem>
+ <bcf:sortitem order="2">title</bcf:sortitem>
+ </bcf:sort>
+ <bcf:sort order="5">
+ <bcf:sortitem order="1">sortyear</bcf:sortitem>
+ <bcf:sortitem order="2">year</bcf:sortitem>
+ </bcf:sort>
+ <bcf:sort order="6">
+ <bcf:sortitem order="1">volume</bcf:sortitem>
+ <bcf:sortitem order="2">0</bcf:sortitem>
+ </bcf:sort>
+ </bcf:sortingtemplate>
+ <!-- DATALISTS -->
+</bcf:controlfile>
diff --git a/taller/docs/latex/report.pdf b/taller/docs/latex/report.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..ac0f4a6a6c86f377e25318b296b68494665c50b5
Binary files /dev/null and b/taller/docs/latex/report.pdf differ
diff --git a/taller/docs/latex/report.run.xml b/taller/docs/latex/report.run.xml
new file mode 100644
index 0000000000000000000000000000000000000000..89c061a4356379124c2b8b290e6763c9c842723f
--- /dev/null
+++ b/taller/docs/latex/report.run.xml
@@ -0,0 +1,82 @@
+<?xml version="1.0" standalone="yes"?>
+<!-- logreq request file -->
+<!-- logreq version 1.0 / dtd version 1.0 -->
+<!-- Do not edit this file! -->
+<!DOCTYPE requests [
+ <!ELEMENT requests (internal | external)*>
+ <!ELEMENT internal (generic, (provides | requires)*)>
+ <!ELEMENT external (generic, cmdline?, input?, output?, (provides | requires)*)>
+ <!ELEMENT cmdline (binary, (option | infile | outfile)*)>
+ <!ELEMENT input (file)+>
+ <!ELEMENT output (file)+>
+ <!ELEMENT provides (file)+>
+ <!ELEMENT requires (file)+>
+ <!ELEMENT generic (#PCDATA)>
+ <!ELEMENT binary (#PCDATA)>
+ <!ELEMENT option (#PCDATA)>
+ <!ELEMENT infile (#PCDATA)>
+ <!ELEMENT outfile (#PCDATA)>
+ <!ELEMENT file (#PCDATA)>
+ <!ATTLIST requests
+ version CDATA #REQUIRED
+ >
+ <!ATTLIST internal
+ package CDATA #REQUIRED
+ priority (9) #REQUIRED
+ active (0 | 1) #REQUIRED
+ >
+ <!ATTLIST external
+ package CDATA #REQUIRED
+ priority (1 | 2 | 3 | 4 | 5 | 6 | 7 | 8) #REQUIRED
+ active (0 | 1) #REQUIRED
+ >
+ <!ATTLIST provides
+ type (static | dynamic | editable) #REQUIRED
+ >
+ <!ATTLIST requires
+ type (static | dynamic | editable) #REQUIRED
+ >
+ <!ATTLIST file
+ type CDATA #IMPLIED
+ >
+]>
+<requests version="1.0">
+ <internal package="biblatex" priority="9" active="1">
+ <generic>latex</generic>
+ <provides type="dynamic">
+ <file>report.bcf</file>
+ </provides>
+ <requires type="dynamic">
+ <file>report.bbl</file>
+ </requires>
+ <requires type="static">
+ <file>blx-dm.def</file>
+ <file>blx-compat.def</file>
+ <file>biblatex.def</file>
+ <file>numeric.bbx</file>
+ <file>standard.bbx</file>
+ <file>numeric.cbx</file>
+ <file>biblatex.cfg</file>
+ <file>spanish.lbx</file>
+ </requires>
+ </internal>
+ <external package="biblatex" priority="5" active="1">
+ <generic>biber</generic>
+ <cmdline>
+ <binary>biber</binary>
+ <infile>report</infile>
+ </cmdline>
+ <input>
+ <file>report.bcf</file>
+ </input>
+ <output>
+ <file>report.bbl</file>
+ </output>
+ <provides type="dynamic">
+ <file>report.bbl</file>
+ </provides>
+ <requires type="dynamic">
+ <file>report.bcf</file>
+ </requires>
+ </external>
+</requests>
diff --git a/taller/docs/latex/report.tex b/taller/docs/latex/report.tex
new file mode 100644
index 0000000000000000000000000000000000000000..4ac02d2408079ebd1dc4348a95b28f683f3bdf4e
--- /dev/null
+++ b/taller/docs/latex/report.tex
@@ -0,0 +1,2197 @@
+\documentclass[a4paper, 11pt]{report}
+
+%% Language and font encodings
+\usepackage[spanish]{babel}
+\usepackage[utf8x]{inputenc}
+\usepackage[T1]{fontenc}
+
+%% Sets page size and margins
+\usepackage[a4paper,top=3cm,bottom=2cm,left=2cm,right=2cm,marginparwidth=1.75cm]{geometry}
+
+%% Useful packages
+\usepackage{amsmath}
+\usepackage{graphicx}
+\usepackage{multicol}
+\usepackage{algorithm,algorithmic}
+\usepackage{subcaption}
+\usepackage{fancyhdr}
+\graphicspath{ {resources/} }
+\usepackage[colorinlistoftodos]{todonotes}
+\usepackage[colorlinks=true, allcolors=black]{hyperref}
+\usepackage{enumitem}
+\usepackage{listings}
+\lstset{
+ breaklines=true,
+ basicstyle=\small\ttfamily,
+ columns=flexible,
+ gobble=4,
+ tabsize=4,
+ showstringspaces=false
+ }
+
+
+\setlength{\columnseprule}{1pt}
+
+\setlength{\headheight}{25pt}
+
+\addto\captionsspanish{% Replace "english" with the language you use
+ %% Cambio el nombre del índice
+ \renewcommand{\contentsname}{Índice}
+ %% Remuevo la palabra capítulo de los títulos
+ \renewcommand{\chaptername}{}
+}
+
+\font\titleFont=cmr12 at 30pt
+
+\title{{\Huge Despliegue de un Datacenter con Openstack}}
+
+\author{Matías Capucho, Santiago Elizondo \\
+ Universidad de la República, Montevideo, Uruguay. \\
+ Email: \href{mailto:matias.capucho@fing.edu.uy}{matias.capucho@fing.edu.uy}, \href{mailto:selizondo@fing.edu.uy}{selizondo@fing.edu.uy} }
+
+\date{4 de Agosto de 2019}
+
+\pagestyle{fancy}
+
+
+\begin{document}
+\maketitle
+
+\begin{abstract}
+El presente documento estudia los aspectos fundamentales de la plataforma Openstack. A su vez, relata el proceso de diseño, instalación, y configuración básica de un Datacenter mediante la utilización de dicha plataforma. Se especifican los pasos necesarios a seguir y se detallan puntos sumamente relevantes a tener en cuenta.
+\end{abstract}
+
+\tableofcontents
+
+\chapter{Introducción}
+En la actualidad hay un fuerte potencial de crecimiento en los datacenters, principalmente dado por la demanda de sus servicios provenientes de nuevas tendencias como la digitalización de la información, el crecimiento del comercio electrónico y la adopción del cloud computing como una alternativa real. En función de esto resulta sumamente interesante investigar alternativas y procedimientos que deben ser llevados a cabo para desplegar y operar un datacenter.\\
+
+Una tendencia que fue en aumento en los últimos años es la utilización de Openstack como plataforma de despliegue y gestión. Por lo tanto la finalidad de este informe será relatar una primera experiencia con dicha plataforma en una ambiente de prueba en el Instituto de Computación de la Facultad de Ingeniería.
+
+
+\chapter{Marco teórico}
+A continuación se presentan conceptos introductorios relevantes para comprender el estudio que se desarrollará más adelante en el informe.
+\section{Cloud computing}
+Cloud computing resulta ser un modelo que involucra tanto a los servicios computacionales provistos a los clientes a través de Internet, como a la implementación de hardware y software que logra proveerlos. Esta implementación se aloja en los denominados datacenters, que integran adecuadamente los diversos recursos tales como redes, servidores, almacenamiento y software necesarios para ofrecer los mencionados servicios en función de la demanda.
+Este modelo computacional, impulsado durante el siglo 21, ha evolucionado velozmente y ha migrado el mundo de TI de las antiguas PCs locales de usuarios y de los cuartos de servidores empresariales a la llamada “nube” alojada en lejanos datacenters.\\
+Según la definición brindada por The National Institute of Standards and Technology (NIST) \cite{sp800-145}, la computación en la nube debe cumplir con 5 características esenciales:
+\begin{itemize}
+ \item \textbf{On-demand self-service}: los servicios alojados deben poder obtener capacidad de cómputo a demanda, consumiendo los recursos requeridos y sin que exista interacción humana con proveedores.
+ \item \textbf{Broad network access}: los servicios deben encontrarse disponibles a través de la red y accesibles mediante mecanismos estándares.
+ \item \textbf{Resource pooling}: los recursos computacionales se mantienen en grupos pudiendo ser asignados a múltiples consumidores en forma dinámica según la demanda necesaria.
+ \item \textbf{Rapid elasticity}: los recursos deben poder escalar en forma sencilla e incluso automática en función de la demanda. De esta forma, los consumidores de servicios tendrán una visión de la nube como una fuente de recursos ilimitada.
+ \item \textbf{Measured service}: los recursos consumidos deben ser monitorizados y medidos con un determinado nivel de abstracción en función del servicio provisto. Deben existir reportes de consumo que brinden absoluta transparencia tanto al proveedor como al consumidor.
+\end{itemize}
+
+Estas propiedades ambiciosas demuestran que brindar un servicio de cloud no es para nada trivial y requiere grandes conocimientos de TI a la hora de diseñar y poner un marcha un datacenter.\\
+
+En cuanto a los modelos de cloud computing, existen tres clasificaciones que se distinguen según el tipo de servicio provisto \cite{Zhang2010}:
+
+\begin{itemize}
+ \item \textbf{Software as a Service (SaaS)}: refiere al servicio que provee aplicaciones a través de internet que se encuentran corriendo en la infraestructura de la nube (datacenter). Los consumidores del servicio no manipulan la infraestructura subyacente ni las configuraciones de aplicación.
+ \item \textbf{Platform as a Service (Paas)}: consiste en proveer recursos a nivel de plataforma, como por ejemplo soporte de sistemas operativos, que permiten al cliente desplegar sus propias aplicaciones. El consumidor no puede manipular la infraestructura pero sí es capaz de manipular lo que se despliega sobre ella.
+ \item \textbf{Infrastructure as a Service (IaaS)}: se asocia al suministro de recursos de infraestructura a demanda. Se suele proveer al cliente de capacidad de procesamiento, almacenamiento y conectividad de red. Típicamente se ofrecen máquinas virtuales con la posibilidad de que el cliente manipule los sistemas operativos y las aplicaciones. Nuevamente el consumidor no es capaz de influir en la infraestructura que implementa la nube.
+\end{itemize}
+
+\section{Virtualización}
+Uno de los principales conceptos que se encuentra involucrado en la implementación de cloud computing es el de virtualización \cite{redhat-virtualization}\cite{vmware-virtualization}. Esta tecnología permite simular diversos ambientes con recursos dedicados a partir de un solo sistema físico. Es posible crear aplicaciones, servidores, almacenamiento y redes, utilizando al máximo todos los recursos del sistema subyacente aumentando el rendimiento general. Los usuarios finales interactúan directamente con las virtualizaciones, llamadas máquinas virtuales. Una máquina virtual puede ser transferida de un sistema host a otro y funcionar de igual forma.
+
+La implementación de esta tecnología se da mediante los denominados \textbf{hipervisores} \cite{redhat-virtualization}\cite{oracle-hypervisors}, los cuales se encargan de conectar los recursos físicos de la máquina host con las máquinas virtuales. Estos trabajan sobre el sistema operativo o directamente en el hardware, creando una plataforma virtual, que divide los recursos físicos, sobre la cual se ejecutan las diferentes virtualizaciones. Por otro lado también son responsables de crear ambientes aislados que brinden seguridad entre las máquinas virtuales.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.4\columnwidth]{hypervisors}
+ \caption{Hipervisores. Extraída de \cite{redhat-virtualization}.}
+ \label{hiper}
+\end{figure}
+
+Los hipervisores se suelen clasificar en dos tipos:
+\begin{itemize}
+ \item \textbf{Nativos o bare metal}: se trata de software que corre directamente sobre el hardware del sistema host, controlando el hardware y monitoreando el sistema operativo invitado. Algunos ejemplos son Oracle VM, Microsoft Hyper-V, VMware ESXi y Xen.
+ \item \textbf{Alojados o hosted}: consisten en hipervisores que corren dentro de un sistema operativo tradicional. Se encuentran en una capa de aplicación por encima del sistema operativo del host pero por debajo del sistema operativo guest. Algunos ejemplos son Oracle VM VirtualBox, VMware Server y Workstation, Microsoft Virtual PC, KVM, QEMU y Parallels.
+\end{itemize}
+
+\subparagraph{KVM}
+\cite{redhat-kvm}, siglas de Kernel-based Virtual Machine, se trata de una tecnología de virtualización open source sobre Linux. Se encuentra formada por un módulo del kernel denominado kvm.ko y permite transformar un sistema operativo Linux en un hipervisor. Como módulo del kernel se encuentra incluido en Linux a partir de la versión 2.6.20. Como hipervisor se clasifica como de tipo alojado, o hosted, utilizando los componentes del sistema Linux para implementar cada máquina virtual como un proceso de Linux.
+
+\section{Contenerización}
+Un contenedor \cite{docker-containers} es una unidad de software liviana diseñada para ejecutar una aplicación. Está formado únicamente por el código de la aplicación y las dependencias necesarias para que esta ejecute, creando un paquete portable e independiente. De esta forma múltiples contenedores pueden correr como procesos diferentes en una misma máquina host compartiendo el kernel del sistema operativo.
+Si bien tanto contenedores como máquinas virtuales tienen como fin aislar y compartir recursos de la máquina host, lo hacen en diferentes niveles. Los primeros virtualizan únicamente el sistema operativo guest, utilizando el kernel del host subyacente, mientras que las VMs virtualizan a nivel de hardware.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{containers}
+ \caption{Virtualización vs Contenerización. Extraída de \cite{redhat-lxc}.}
+ \label{containers}
+\end{figure}
+
+La combinación de estas tecnologías provee gran flexibilidad al realizar el despliegue de aplicaciones sobre varios servidores, complementando lo ligero de los contenedores con el aislamiento de recursos físicos y la seguridad obtenidos mediante VMs.\\
+Citando la ‘Application Container Security Guide’ (SP 800-190 de NIST \cite{sp800-190}): \textsl{“A pesar de que a veces se considera que los contenedores son la siguiente fase de virtualización, sobrepasando la virtualización de hardware, la realidad de la mayoría de las organizaciones apunta menos a la revolución que a la evolución. Los contenedores y la virtualización de hardware no solo pueden, sino que frecuentemente lo hacen, coexistir y heredar las capacidades del otro. Las VMs brindan muchos beneficios, tales como fuerte aislamiento, automatización de SO, y un amplio y profundo ecosistema de soluciones. Las organizaciones no necesitan tomar una decisión entre contenedores y máquinas virtuales. Por el contrario pueden continuar utilizando VMs para desplegar, particionar y administrar su hardware, mientras que utilizan contenedores para empaquetar sus aplicaciones, aprovechando cada VM más eficientemente.”}\\
+Es por esto que ambas tecnologías serán utilizadas más adelante en la puesta en marcha de un datacenter de prueba mediante Openstack.
+
+\subparagraph{LXC}
+\cite{arch-lxc}\cite{redhat-lxc} Un “Linux container” es un contenedor formado por un conjunto de procesos que se encuentran aislados del resto del sistema host. Como tal, brinda un entorno virtual con su propia CPU, memoria, red, etc, implementado mediante el uso de los namespaces y cgroups del kernel linux corriendo en la máquina host.\\
+Este tipo de contenedores es utilizado por Openstack durante su despliegue para ejecutar los servicios en cuya configuración se haya indicado que utilicen contenedores en lugar de correr directo sobre el servidor.
+
+\section{Datacenters}
+La infraestructura que se encuentra por debajo de la mencionada nube se conoce con el nombre de Datacenter. Un Datacenter \cite{cisco-datacenter} es un espacio físico que aloja múltiples componentes de hardware interconectados tales como servidores, racks, switches, routers, sistemas de almacenamiento, etc. Estos últimos proveen una red de recursos de red, cómputo y almacenamiento, necesaria para alojar diversas aplicaciones o grandes cantidades de datos. A su vez, los nuevos Datacenters escalan implementando infraestructuras virtualizadas, utilizando los mecanismos mencionados anteriormente, por encima de la física ya existente llegando a interconectar múltiples espacios físicos ubicados en diversas partes del mundo.
+\\
+Debido al gran potencial computacional existente en este tipo de infraestructuras, su mayor explotación se encuentra en la ejecución de tecnologías tales como big data, inteligencia artificial, aprendizaje automático, entre otras.
+\\
+Por su gran importancia en la tecnología de la información actual, los Datacenters no solo requieren un diseño de infraestructura de recursos computacionales sino también un diseño de componentes físicos externos que garanticen la seguridad física y una tasa de resistencia a fallas prácticamente perfecta. En función de estos aspectos es que existe un estándar internacional especificado por la ANSI que califica y certifica el diseño de un datacenter. Existen entonces cuatro categorías bajo el estándar ANSI/TIA-942 que se resumen a continuación:
+
+\begin{itemize}
+ \item \textbf{TIER 1}: especificado para pequeñas empresas y organizaciones con una infraestructura básica. Ofrece una escasa protección ante riesgos físicos externos, sin la implementación de ninguna redundancia.
+ \item \textbf{TIER 2}: se corresponde a Datacenters que posean un mínimo nivel de redundancia a nivel de componentes pero no de distribución eléctrica. Además aumentan su protección en cuanto a eventos físicos, en comparación con el nivel anterior.
+ \item \textbf{TIER 3}: suele indicarse para organizaciones que requieren un servicio con disponibilidad 24/7. Mantiene redundancia tanto a nivel de componentes como de distribución eléctrica. Tolera prácticamente cualquier tipo fallas físicas. Para mantener el sistema (ej: recambio de componentes) no es necesario paralizarlo.
+ \item \textbf{TIER 4}: enfocado a grandes organizaciones mundiales. Mantiene el mayor nivel de tolerancia a fallas junto con redundancia de componentes y distribuciones eléctricas. Es posible que ocurra un mantenimiento del sistema junto con una falla inesperada sin que el servicio se vea afectado.
+\end{itemize}
+
+\section{Redes}
+En la etapa de configuración e instalación y posteriormente en la utilización de Openstack, se referencian diversos conceptos de red, por ejemplo, protocolos, tipos de redes y componentes virtualizados. A continuación se introducirán brevemente algunos de estos conceptos.
+
+\subparagraph{Flat}
+Una red Flat hace referencia a una red en la cual no se utiliza ningún tipo de tag. Las interfaces físicas o virtuales se asocian directamente al switch o bridge por lo tanto solamente una red flat puede existir por cada interfaz física.
+
+\subparagraph{VLAN}
+Una Virtual Local Area Network (VLAN) permite segmentar de manera virtual un dominio de difusión de capa 2 en múltiples dominios de difusión. Esto permite utilizar un switch como si fuera múltiples switches. A modo de ejemplo, dos host conectados a un mismo switch pero en distintas VLANs no podrán ver el tráfico generado por el otro.
+Para identificar a qué VLAN corresponde una trama se utiliza un nuevo campo en el cual se introduce el ID de la VLAN, estos cambios que se realizan a la trama Ethernet se establecen en el estándar IEEE 802.1Q \cite{802.1Q}.\\
+Openstack utiliza las VLANs con el fin de aislar el tráfico de datos de diferentes clientes, sin importar en qué servidor físico (nodo de cómputo) estén corriendo las máquinas de los mismos \cite{openstack-basic-networking}.
+
+\subparagraph{VXLAN}
+El protocolo Virtual extensible local area network (VXLAN) se ubica dentro de los protocolos de superposición (overlay protocols) que utilizan el mecanismo de tunelización para el transporte de datos. VXLAN encapsula una trama Ethernet dentro de paquetes UDP los cuales pueden ser ruteados. Esto permite extender una red local sobre múltiples redes de capa 3 en forma transparente para los host finales. El funcionamiento del protocolo se encuentra en el RFC 7348 \cite{rfc7348}.\\
+Para diferenciar las distintas redes virtuales en lugar de utilizar un VLAN ID se utiliza un VXLAN Network Identifier (VNI), el cual puede tomar aproximadamente 16 millones de valores siendo una de las principales diferencias con las VLANs que pueden tomar 4096 valores únicos. Esta diferencia para datacenters de gran porte es vital para poder aislar el tráfico de los clientes del mismo. Un componente necesario para encapsular y desencapsular son los VXLAN Tunnel Endpoint (VTEP) los cuales residen en los nodos físicos. Un listado con pros y contras de las redes de capa 2 y capa 3 se presenta en \cite{openstack-networking-concepts}.
+
+\chapter{Openstack}
+
+\section{Origen y definición}
+Openstack fue creado en los primeros meses del 2010. En ese momento Rackspace quería reescribir el código de infraestructura que corría en sus servidores cloud y además estaban considerando hacer open source el código cloud existente. En ese entonces, Anso Labs, quienes trabajaban para la NASA, publicaron el código beta para Nova, un proyecto basado en Python descrito como “cloud computing fabric controller”. Dadas las semejanzas en las necesidades de ambas empresas, decidieron en unir fuerzas dando como resultado una base de Openstack. \\
+
+El primer Summit de diseño tuvo lugar en Austin, TX del 13 al 14 de julio de 2010, en donde participaron aproximadamente 25 compañías: AMD, Autonomic Resources, Citrix, Cloud.com, Cloudkick, Cloudscaling, CloudSwitch, Dell, enStratus, FathomDB, Intel, iomart Group, Limelight, Nicira, NTT DATA, Opscode, PEER 1, Puppet Labs, RightScale, Riptano, Scalr, SoftLayer, Sonian, Spiceworks, Zenoss y Zuora. El proyecto fue oficialmente anunciado el 21 de julio de ese mismo año. \\
+
+Originalmente la misión de Openstack era “to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable”. Luego en 2016 se actualizó la misma incluyendo interoperabilidad y mejor servicio a los usuarios finales. En septiembre de 2012, fue lanzada la fundación de Openstack como una institución independiente proporcionando recursos para proteger, potenciar y promover el software Openstack y la comunidad que lo rodea \cite{openstack-history}. Como es definido en el sitio de Openstack, \textsl{“es un sistema operativo en la nube que controla grandes grupos de recursos de computación, almacenamiento y redes a través de un centro de datos, administrados y provisionados a través de APIs”}\cite{openstack-software}.\\
+
+Openstack es un software open source gobernado por una fundación. Ser parte de la misma es gratis y está abierta a todo el mundo. El proyecto tiene una arquitectura modular, en donde cada instalación de Openstack tendrá instalados y configurados los módulos que se ajusten a las necesidades del caso. Dichos módulos están implementados en Python. Seis de estos proyectos se denominan como módulos core dado que se encargan de las funciones principales del cloud como son las conexiones de red, el almacenamiento, el servicio de identidad, servicios de imágenes y de cómputo. Permite construir nubes públicas y privadas ofreciendo principalmente servicios de infraestructura (IaaS) y en un grado menor, servicios de plataforma (PaaS).
+
+\section{Módulos Core}
+En esta sección se describirán los módulos Nova, Neutron, Glance, Cinder, Keystone y Swift, llamados core, profundizando en los aspectos más importantes de cada uno. Conceptualmente los módulos se relacionan de la siguiente forma:
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{openstack-modules}
+ \caption{Relacionamiento entre módulos core}
+ \label{modules}
+\end{figure}
+
+En \cite{openstack-design} se muestra un esquema de una arquitectura lógica estándar de Openstack, en donde se puede apreciar las interacciones internas entre los componentes de un proyecto, las interacciones entre proyectos y las interacciones entre agentes externos y openstack.
+
+\subsection{Keystone}
+Keystone es el servicio de identidad que utiliza Openstack para la autenticación y autorización. El mismo se organiza como un conjunto de servicios internos, que se exponen en uno o varios endpoints, listados a continuación:
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{keystone}
+ \caption{Servicios y backends soportados por Keystone. Extraída de \cite{openstack-idm-book-1}.}
+ \label{keystone}
+\end{figure}
+
+\begin{itemize}
+ \item El \textbf{servicio de identidad} autenticación e información de usuarios y grupos. En una instalación estándar este servicio se encarga de todas las operaciones referentes a estos datos, sin embargo en instalaciones más complejas se pueden configurar distintos backends para llevar a cabo estas tareas. Un ejemplo de esto puede ser LDAP.
+ \begin{itemize}
+ \item Un usuario representa a un consumidor individual de la API el cual necesariamente debe pertenecer a un dominio y es único dentro del mismo.
+ \item Un grupo representa un conjunto de usuarios, los cuales al igual que los usuarios, deben pertenecer a un único dominio.
+ \end{itemize}
+ \item El \textbf{servicio de recursos} provee información sobre proyectos y dominios.
+ \begin{itemize}
+ \item Los proyectos representan la unidad base de propiedad en Openstack, debido a que todos los recursos deben pertenecer a un proyecto necesariamente. Los proyectos son únicos dentro de cada dominio.
+ \item Los dominios son grandes contenedores para los proyectos, grupos y usuarios. Por defecto Openstack crea el dominio “Default”. Dada la naturaleza de los dominios los mismos pueden ser utilizados para delegar la administración de los recursos.
+ \end{itemize}
+ \item El \textbf{servicio de asignación} provee información sobre roles y asignaciones.
+ \begin{itemize}
+ \item Un rol indica el nivel de autorización que un usuario final puede obtener. Un rol se puede otorgar a nivel de dominio o proyecto. Por otro lado un rol puede ser asignado a nivel de usuario o grupo.
+ \item Las asignaciones de roles son tripletas que contienen un rol, un recurso y una identidad.
+ \end{itemize}
+ \item El \textbf{servicio de Tokens} válida y administra los tokens utilizados para las solicitudes de autenticaciones enviadas luego que las credenciales del usuario fueron validadas.
+ \item El \textbf{servicio de catálogo} utilizado para el descubrimiento de endpoints.
+\end{itemize}
+
+Las definiciones mencionadas fueron extraídas de \cite{openstack-keystone-architecture} y \cite{openstack-idm-book}.
+
+\subsection{Nova}
+Nova es el proyecto que se encarga de proveer una forma para provisionar instancias o servidores virtuales. El proyecto soporta la creacion de imagenes, servidores baremetal con la ayuda del proyecto ironic y un soporte limitado para el manejo de containers.\\
+Nova se compone por un conjunto de demonios que permiten ofrecer los servicios mencionados. Adicionalmente para poder desarrollar las funciones básicas, este módulo requiere de los siguientes servicios core de openstack: keystone, glance, neutron y placement.\\
+
+En la figura \ref{nova} se puede apreciar un esquema conceptual de los principales componentes de una instalación de nova estándar.
+Un dato relevante sobre los componentes de nova es que pueden ser escalados horizontalmente, siendo independiente el grado de escalado para cada servicio.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{nova}
+ \caption{Principales componentes de Nova. Extraída de \cite{openstack-nova-architecture}.}
+ \label{nova}
+\end{figure}
+
+Internamente los componentes de nova se comunican mediante RPC mientras que la interfaz de cara al usuario es una API REST.
+Los principales componentes de nova son:
+
+\subparagraph{API}
+Se encarga de recibir y responder las solicitudes HTTP y comunicarse con los otros componentes de nova mediante la cola de mensajes.
+
+\subparagraph{Scheduler}
+Se encarga de decidir en qué host de cómputo se aloja cada instancia. Para tomar estas decisiones existen diversos algoritmos que pueden ser configurados, siendo algunos ejemplos el algoritmo simple donde selecciona el host con menor carga actual, chance en donde se elige un nodo de forma randómica, entre otros. Esta tarea puede ser muy sencilla como es el caso del algoritmo random o muy complicada para los casos donde se requiera realizar un uso eficiente de los recursos \cite{openstack-deploying-book}.
+
+\subparagraph{Compute}
+El módulo nova-compute es principalmente un demonio que se encarga de administrar la comunicación con el hypervisor y con las máquinas virtuales. Esto lo lleva a cabo mediante las APIs del hipervisor. Algun ejemplos de APIs son: libvirt para KVM o QEMU, XenAPI para XenServer y VMwareAPI para VMware.\\
+Haciendo a un lado la complejidad del módulo, básicamente el demonio acepta acciones de la cola de mensajes para luego realizar una serie de comandos contra la API del hipervisor. Además se encarga de actualizar el estado de la base de datos \cite{openstack-compute-overview}.
+
+\subparagraph{Conductor}
+En las primeras versiones de Openstack, todos los servicios del componente de cómputo tenían acceso directo a la base de datos hosteada en el nodo controlador. Esto presentaba dos grandes problemas: seguridad y performance. En lo que respecta a la seguridad, en el caso que un nodo de cómputo sea vea comprometido, el atacante tendrá acceso a la base de datos de Openstack. Por el lado de la performance, las llamadas realizadas desde el nodo de cómputo soportan un único hilo y son bloqueantes. Esto generaba un cuello de botella debido a no poder paralelizar las invocaciones. \\
+Para mejorar estos dos aspectos se introdujo el servicio nova-conductor el cual se presenta como una capa por encima del servicio de cómputo. Nova-compute en lugar de acceder directamente a la BD, delega la responsabilidad al servicio nova-conductor. En otras palabras este servicio actúa como un proxy para el servicio nova-compute. \\
+El problema de seguridad se resuelve dado que los nodos de cómputo dejan de acceder directamente a la BD y el de performance se resuelve gracias a que el servicio de nova-conductor es no bloqueante, permitiendo realizar múltiples invocaciones en paralelo \cite{openstack-control-plane}.
+Por los motivos de su existencia, este servicio no se debe instalar en los nodos de cómputo. \cite{redhat-conductor}. \\
+Además puede servir como un lugar donde centralizar y permitir administrar las operaciones que involucran al scheduler y el servicio de computo cómo construir, cambiar el tamaño o migrar instancias. Esto se realiza con el fin de separar las responsabilidades entre los servicios de nova. En \cite{redhat-conductor} se muestra un ejemplo de los beneficios que este cambio presenta.
+
+\subparagraph{Placement}
+Este servicio se presenta como una API REST que se encarga de realizar un seguimiento de los proveedores de recursos. Los recursos pueden ser de distintas clases. A modo de ejemplo un proveedor puede ser un nodo de cómputo o un pool de storage.
+
+\subsection{Neutron}
+Neutron es el proyecto encargado de proveer y administrar recursos de red en una nube creada con Openstack. Es un sistema escalable horizontalmente y diseñado para añadirle diversos plugins con el fin de proporcionar nuevas funcionalidades. Como otros servicios de Openstack, Neutron requiere una base de datos para persistir las configuraciones de los elementos de red. El servicio de red de Openstack permite crear desde redes y subredes hasta topologías de red avanzadas las cuales pueden contener firewalls, balanceadores, VPNs entre otros. \\
+
+Las instalaciones del módulo de red deben tener al menos un red externa, la cual no es una SDN definida dentro de Openstack sino que es una red accesible por fuera de Openstack. Estas redes permiten que las redes virtuales construidas con neutron tengan conectividad con el mundo exterior. Por otro lado, neutron permite crear redes internas a las cuales se conectarán directamente las VMs. Para lograr que dichas VMs se conecten con las redes externas son necesarios routers que relacionen ambos tipos de redes.\\
+
+Una arquitectura simplificada de Neutron se puede ver en la figura \ref{neutron2}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.7\columnwidth]{neutron2}
+ \caption{Extraída de \cite{openstack-networking-book-2}}
+ \label{neutron2}
+\end{figure}
+
+\subparagraph{Neutron-server}
+El módulo Neutron server es en donde reside la API recibiendo y respondiendo las solicitudes de recursos de red. El servidor se comunica con la base de datos para almacenar las configuraciones existentes como se mencionó previamente.
+
+\subparagraph{Plugins y agentes}
+Por otro lado se encuentran una serie de agentes que se distribuyen típicamente en los nodos de red y cómputo. Estos agentes se agregan a demanda según las funcionalidades y rendimiento requeridos. Estos agentes o plugins serán los encargados de crear los recursos virtuales de red del cloud.
+
+\subparagraph{Cola de mensajes}
+En general se utiliza en las instalaciones del módulo de red para llevar a cabo la comunicación entre el neutron-server y los distintos agentes.\\
+
+En la figura \ref{neutron2} se muestra como el servidor de Neutron se conecta con la base de datos que es donde se persisten los recursos de red creados. Por otro lado el servidor acepta solicitudes en la API que expone desde los usuarios y servicios.
+
+\subsubsection{Tipos de redes en Openstack}
+En Openstack los usuarios tienen la posibilidad de crear su propio esquema de red, decidiendo libremente el direccionamiento IP a utilizar. Los recursos de red creados dentro de un proyecto son privados al mismo. En Openstack se pueden crear dos tipos de redes:
+
+\begin{itemize}
+ \item \textbf{Project/tenant network}: es una red virtual creada por un proyecto o por un administrador en nombre del proyecto. Este tipo de red se encarga de proveer conectividad a los recursos de un proyecto. Los usuarios pueden crear, modificar y eliminar redes tenants. En general este tipo de redes está aislado del resto de las redes de proyecto por VLANs o algún otro mecanismo de segmentación como VXLAN.
+ \item \textbf{Provider network}: s una red virtual creada para mapearse a una red física de los servidores que alojan Openstack. Este tipo de redes son creadas para habilitar el acceso a recursos de red externos a la nube de Openstack. Las mismas son creadas y administradas por los administradores.
+\end{itemize}
+
+Cuando se crea una red de proyecto los aspectos físicos de como es implementada son transparentes al usuario, por lo contrario en la red de proveedor se puede especificar el tipo de red, la interfaz física y el identificador de segmentación utilizado.
+
+\subsubsection{Tipo de tráfico}
+El tráfico en Openstack se puede dividir en dos categorías: plano de control y plano de datos. El plano de control está relacionado con el tráfico utilizado para administración de los nodos físicos o contenedores, para las API de los servicios de Openstack y todo el tráfico que no esté relacionado con las instancias virtuales de Openstack. El plano de datos está relacionado con el tráfico generado o dirigido hacia instancias virtuales.\\
+
+En ambientes de producción es recomendable utilizar interfaces físicas diferentes para los distintos tipos de tráficos \cite{openstack-networking-book-3}. La decisión de colapsar todo el tráfico en una sola interfaz y segmentarlo con VLANs o utilizar múltiples interfaces depende de las necesidades de cada caso. Al utilizar una sola interfaz física las probabilidades de fallas de red aumentan.
+
+\subsection{Glance}
+Glance es el nombre del proyecto utilizado por Openstack para la administración de imágenes. Este servicio permite a los usuarios, a través de una API RESTful, gestionar tanto las imágenes de las máquinas virtuales como la metadata asociada a estas. Típicamente esta gestión involucra el descubrimiento, registro y obtención de los recursos mencionados.
+\\
+La implementación del servicio Glance se basa en una arquitectura cliente-servidor, comprendida por los siguientes componentes principales:
+
+\begin{itemize}
+ \item \textbf{Cliente}: es quien realiza pedidos a través de la API REST provista.
+ \item \textbf{API REST}: permite exponer todos los servicios ofrecidos por Glance.
+ \item \textbf{Database Abstraction Layer}: es una API interna encargada de comunicar el servicio glance con la base de datos.
+ \item \textbf{Glance Domain Controller}: se trata de un middleware que implementa las principales funcionalidades (autorización, notificaciones, políticas, conexiones a la base de datos).
+ \item \textbf{Glance Store}: formado por un conjunto de drivers que permiten comunicar Glance con los diferentes backends de almacenamiento posibles.
+\end{itemize}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{glance}
+ \caption{Componentes del módulo Glance. Extraída de \cite{openstack-glance-architecture}.}
+ \label{glance}
+\end{figure}
+
+Las imágenes son un concepto fundamental en Openstack debido a que son necesarias para crear instancias. Una instancia es una determinada máquina virtual que corre físicamente en un nodo de cómputo específico, siendo creada a partir de una imagen. Además de la imagen es necesario seleccionar un sabor (flavor) que determina las especificaciones de los recursos virtuales asignados a la VM, como pueden ser cantidad de CPUs, MB de memoria RAM y espacio en disco.
+
+\subparagraph{Creación de una VM}
+Cuando se lanza una VM, en general y a grandes rasgos se llevan a cabo los siguientes pasos:
+\begin{enumerate}
+ \item Se selecciona una imagen administrada por Glance y un flavor que indica tanto los recursos de cómputo necesarios a ser instanciados por Nova como de almacenamiento gestionados por Cinder.
+ \item El nodo de cómputo copia la imagen de base copiada desde Glance hacia el disco principal de la VM conectándose en forma remota con el servicio de Cinder.
+ \item El nodo de cómputo provee los recursos virtuales como vCPUs y memoria.
+ \item La instancia levanta y comienza a ejecutar. Cualquier modificación almacenada en el disco de la instancia no altera la imagen de base original que seguirá estando disponible para lanzar nuevas instancias.
+\end{enumerate}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{glance2}
+ \caption{Extraída de \cite{openstack-images-instances}.}
+ \label{glance2}
+\end{figure}
+
+Cuando la instancia deja de existir, se liberan todos los recursos con excepción del almacenamiento persistente en Cinder.\\
+
+Cada imagen tiene asociada su metadata, que incluye conjunto mínimo de propiedades \cite{openstack-image-properties-1}:
+
+\begin{itemize}
+ \item \textbf{arquitecture}: indica la arquitectura de CPU que debe ser soportada por el hipervisor.
+ \item \textbf{instance\_uuid}: en caso de tratarse de una snapshot de una instancia, es utilizada para determinar con cual de ellas se encuentra asociada.
+ \item \textbf{kernel\_id}: el identificador de la imagen que puede ser utilizada como kernel cuando se inicia una imagen AMI (Amazon Machine Image).
+ \item \textbf{ramdisk\_id}: el identificador de la imagen que puede ser utilizada como ramdisk cuando se inicia una imagen AMI.
+ \item \textbf{os\_distro}: el nombre común de la distribución del sistema operativo (en minúsculas).
+ \item \textbf{os\_version}: la versión del sistema operativo, especificada por el distribuidor.
+\end{itemize}
+
+La lista completa de propiedades se encuentra en \cite{openstack-image-properties-2}. Una de las características principales a especificar es el formato de disco o contenedor. El formato de disco de imagen de VM no es más que el formato de la imagen de disco subyacente, este puede ser alguno de los siguientes: raw, vhd, vhdx, vmdk, vdi, iso, ploop, qcow2, aki, ari, ami. Por su parte, el formato de contenedor refiere a aquellos formatos de imágenes que incluyen metadata en sí mismos, pueden ser: bare, ovf, aki, ari, ami, ova, docker.
+
+\subsection{Cinder}
+El servicio de almacenamiento de bloques proporciona administración de almacenamiento de bloques persistente para discos duros virtuales. Las operaciones básicas que permite realizar son:
+
+\begin{itemize}
+ \item Crear, listar y eliminar volúmenes.
+ \item Crear. listar y eliminar snapshots.
+ \item Atachear y desatachear volúmenes a máquinas virtuales.
+\end{itemize}
+
+Los volúmenes son utilizados como una solución para persistir los datos de una instancia incluso luego de destruir la misma. Los volúmenes pueden ser asignados a una instancia a la vez.\\
+
+A continuación se muestra la arquitectura de alto nivel de los componentes de Cinder y cómo interactúan:
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{cinder}
+ \caption{Principales componentes de Cinder. Extraído de \cite{redhat-cinder}.}
+ \label{cinder}
+\end{figure}
+
+El servicio \textbf{cinder-volume} administra la interacción con los dispositivos de almacenamiento de bloque. Al recibir una nueva solicitud del scheduler, el servicio crea, modifica o elimina volúmenes a demanda.\\
+Este servicio incluye en su repositorio un conjunto de drivers para soportar diversos dispositivos de almacenamiento para proveer volúmenes. La instalación por defecto utiliza volúmenes locales administrados por Logical Volume Manager (LVM). Además los drivers pueden soportar diversos protocolos de transporte, en el caso de LVM son iSCSI y iSER \cite{openstack-lvm}. En \cite{openstack-volume-drivers} muestran un listado de los drivers disponibles.\\
+
+El servicio \textbf{cinder-api} recibe y responde las solicitudes del módulo. Este servicio al recibir un nuevo mensaje se encarga en primer lugar de verificar que se cumplan los requerimientos de identidad (tokens), luego en base al mensaje construye uno nuevo indicando las acciones a realizar sobre los volúmenes. El mensaje se envía al broker de mensajes para ser procesado por otros servicios del bloque de almacenamiento.\\
+
+El servicio \textbf{cinder-backup} permite crear backups de los volúmenes a repositorios de almacenamiento externos al proyecto, como por ejemplo realizar los respaldos en Swift.\\
+
+El servicio \textbf{cinder-scheduler} planifica y realiza el ruteo de las solicitudes a los servicios cinder-volume apropiados bajo un criterio definido. Dicho criterio puede ser sencillo como realizar un round robin entre los distintos servicios de volúmenes o ser más sofisticado utilizando filtros de planificación. Estos filtros pueden ser fijados sobre la capacidad, el tipo de volumen, las capacidades funcionales, entre otros.\\
+
+\subsection{Swift}
+Se trata del componente de almacenamiento de objetos de Openstack, implementado mediante un sistema distribuido de alta disponibilidad y accesible a través de una API REST. Gestiona el almacenamiento a largo plazo de grandes cantidades de información utilizando redundancia de datos en clusters bajo una arquitectura que evita tener un único punto de control, permitiendo escalar fácilmente.\\
+
+Swift maneja una jerarquía en tres niveles para organizar el almacenamiento de objetos \cite{openstack-storage-api}:
+
+\begin{itemize}
+ \item \textbf{Account}: la cuenta es el nivel mas alto en la jerarquía, creando un namespace en el cual residen las instancias del siguiente nivel. A nivel de Openstack una cuenta está dada por un proyecto o usuario tenant.
+ \item \textbf{Container}: no es mas que un contenedor de objetos, pero permite gestionar un control de acceso a estos mediante ACLs (no es posible tener ACLs directamente sobre objetos). Como contenedor, define un namespace para los objetos que almacena.
+ \item \textbf{Objeto}: es el contenido a almacenar propiamente dicho, como documentos o imágenes, incluyendo la metadata asociada a estos. Todos los objetos tienen una URL que los identifica para poder ser accedidos.
+\end{itemize}
+
+La siguiente imagen ilustra la arquitectura del servicio Swift, en la cual se pueden identificar componentes clave que serán definidos a continuación \cite{openstack-storage-components}\cite{openstack-storage-architect}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.6\columnwidth]{swift}
+ \caption{Arquitectura del módulo Swift. Extraída de \cite{openstack-storage-components}.}
+ \label{swift}
+\end{figure}
+
+\subparagraph{Principales componentes}
+\begin{itemize}
+ \item \textbf{Proxy servers}: se encargan de comunicar los diferentes componentes del servicio Swift y brindan un acceso público a los usuarios, manejando todos los pedidos que llegan a la API. Para cada uno de los pedidos, busca la ubicación del elemento (cuenta, contenedor u objeto) dentro del anillo para luego acceder al nodo de almacenamiento adecuado.
+ \item \textbf{Rings}: un anillo simboliza el mapeo entre los nombres de los elementos almacenados en el cluster y sus ubicaciones físicas, existiendo anillos separados para cada uno de los tipos de elementos. Cuando el sistema debe realizar una operación sobre un elemento debe interactuar con el anillo correspondiente para poder accederlo. A su vez, los anillos gestionan:
+ \begin{itemize}
+ \item zonas: para generar aislamiento de información.
+ \item dispositivos: determina qué dispositivos se encuentra en uso y cuáles utilizar en caso de falla.
+ \item particiones: distribuidas en forma balanceada en todos los dispositivos.
+ \item réplicas: cada partición es replicada al menos 3 veces, para no tener un único punto de falla.
+ \end{itemize}
+ \item \textbf{Zones}: las zonas son utilizadas para aislar la información almacenada y evitar una pérdida total en caso de fallas. Cada réplica de las mencionadas, intenta ser almacenada en una zona diferente. Cada zona puede ser representada desde un solo disco físico separado, hasta racks servidores completos.
+ \item \textbf{Accounts and containers}: anteriormente se definieron en forma conceptual, pero como componentes cada cuenta o contenedor es implementado mediante una base de datos SQLite distribuida a lo largo del cluster.
+ \item \textbf{Partitions}: cada partición puede estar compuesta por un conjunto de bases de datos de cuentas, bases de datos contenedores y objetos propiamente dichos. Se trata de un agrupamiento de elementos para poder ser trasladados dentro del cluster, facilitando operaciones de replicación.
+\end{itemize}
+
+\section{Tipos de nodos}
+En general los sistemas de Openstack están construidos con servidores o nodos físicos, aunque también es posible utilizarlos virtualizados como es el caso de este trabajo, en donde se pueden agrupar en 4 categorías \cite{openstack-networking-book-1}:
+
+\subparagraph{Nodo de control}
+Estos nodos en general corren las APIs de todos los servicios de los componentes de Openstack. Además estos nodos alojan la base de datos de los módulos, los servidores de mensajes y los componentes de caché en memoria como Memcache. Para escalar horizontalmente las APIs pueden ser instaladas en varios nodos de control pudiendo adicionalmente balancear la carga.
+
+\subparagraph{Nodo de red}
+Estos nodos en general corren los servicios de metadatos y DHCP. Además permiten crear routers virtuales cuando el agente de Neutron L3 es instalado. Al igual que los nodos de control, para mejorar el rendimiento y escalar horizontalmente se pueden separar los servicios de red entre los distintos nodos de red. El uso de nodos de red dedicados mejora la seguridad y resistencia, dado que los nodos de control tendrán menor riesgo de que se sature la red y sus recursos.\\
+
+Un ejemplo de como quedan organizados los componentes de Neutron al utilizar nodos de control, red y computo se muestra a continuación:
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{neutron}
+ \caption{Arquitectura de Neutron. Extraída de \cite{openstack-networking-book-1}.}
+ \label{neutron}
+\end{figure}
+
+En este arquitectura, la API de Neutron es instalada en el nodo de control, los agentes encargados de realizar tareas específicas son instaladas en un nodo dedicado de red y por último, cada nodo de cómputo tiene un agente de red encargado de brindar conectividad a las instancias que aloja.
+
+\subparagraph{Nodo de cómputo}
+Estos nodos en general corren un hipervisor como puede ser KVM. Hyper-V o Xen; o por el lado de los contenedores LXC o Docker.
+
+\subparagraph{Nodo de almacenamiento}
+Estos nodos en general se limitan a correr software que esté relacionado con los proyectos como Cinder, Ceph o Swift. En estos nodos no es común alojar servicios de otro tipo como de red o cómputo.
+
+\subparagraph{Nodo de balanceamiento de carga}
+Estos nodos son fundamentales para el funcionamiento óptimo de una instalación de Openstack, dado que se espera que los servicios que se ofrecen tengan una alta disponibilidad. Como la forma de mejorar el rendimiento es escalar horizontalmente, resulta vital tener nodos que se encarguen de distribuir la carga entre los mismos.
+
+\section{Servicios de infraestructura}
+Estos servicios son transversales a todos los módulos del sistema y son mandatorios para el funcionamiento de Openstack. En general estos servicios son instalados en los nodos de control como fue mencionado en la sección anterior.
+
+\subparagraph{Galera - MariaDB}
+La base de datos MariaDB se utiliza para almacenar el estado de todos los servicios de openstack, utilizando usualmente una base de datos MySQL. El servidor de base de datos en general se despliega con una configuración activo/pasivo en donde solamente el servidor principal (activo) podrá ser utilizado por los servicios. Para poder utilizar un esquema activo/activo se puede utilizar Galera, el cual se define como un software de clusterización para MySQL, el cual utiliza un mecanismo sincrónico de replicación para lograr una alta disponibilidad \cite{openstack-architects-book}.
+
+\subparagraph{Message queue}
+Openstack utiliza una cola de mensajes para llevar a cabo la comunicación entre procesos. Los servicios de cola de mensaje que Openstack soporta son: RabbitMQ y Qpid. Ambos servicios son Advanced Message Queuing Protocol (AMQP) frameworks, los cuales proveen colas de mensajes para comunicaciones punto a punto. En general las colas de mensajes son desplegadas como pools de servidores centralizados o descentralizados. En la instalación realizada se utilizó RabbitMQ \cite{openstack-messaging}.
+
+\subparagraph{Memcached}
+Es un sistema de caché de objetos en memoria distribuido, apuntado a mejorar el rendimiento de los sistemas mediante la reducción de carga a la base de datos. En Openstack este software es utilizado por el mecanismo de autenticación de keystone para cachear los tokens del sistema \cite{openstack-memcached}.
+
+\section{Métodos de instalación}
+Realizar la instalación básica de Openstack (módulos core) es una tarea sumamente compleja. Esto se debe a la gran cantidad de configuraciones y diversos tópicos en los cuales hay que tener un grado de entendimiento no menor, como en bases de datos, linux, redes y backends de almacenamiento. Las guías de instalación que se pueden encontrar en el sitio oficial de openstack consisten de cientos de configuración y comandos a ejecutar en donde es muy probable equivocarse y en consecuencia instalar incorrectamente los módulos de openstack. \\
+
+Debido a la relevancia que ha tomado en los últimos años openstack, la amplia comunidad formada por decenas de compañías y personas buscaron caminos alternativos a realizar la instalación “manualmente”. Estas formas se basan en la automatización de las tareas. Para esto existen varias tecnologías como puppet \cite{openstack-puppet} o Ansible \cite{openstack-ansible}. Además existen diversas distribuciones de Openstack, como DevStack que permite armar un ambiente rápidamente para realizar pruebas, Packstack-RDO o TripleO. Finalmente existe una gran oferta de distribuciones comerciales donde podemos encontrar grandes compañías como IBM, Debian, DELL, Red Hat, VMware, Huawei, etc. Un listado más extenso se puede ver en \cite{openstack-marketplace}.\\
+
+Otra de las razones principales para utilizar herramientas de automatización además de facilitar la instalación es para poder mantener el sistema luego de su instalación. En el caso de realizar las tareas manualmente no se podrá escalar la nube a cientos o miles de servidores dado que sería prácticamente imposible de mantener o actualizar. \\
+
+En el presente trabajo se emplea la herramienta de automatización Ansible dentro del proyecto Openstack-Ansible (OSA). Dicho proyecto se encarga de proveer playbooks y roles para deployar y configurar un ambiente de Openstack. OSA no es un proyecto que funcione simplemente con los archivos y configuraciones por defecto sino que modificaciones por parte del administrador del cloud serán necesarias. El resultado final que se obtiene con OSA es un cloud de Openstack probada para ambientes de cualquier tamaño, desde datacenters de testing hasta producción. \\
+
+Antes de continuar profundizando en las particularidades de OSA se introducirá brevemente Ansible.
+
+\subsection{Ansible}
+Ansible es una herramienta para la automatización de tareas. Permite configurar sistemas, aplicaciones o dispositivos, desplegar o mantener software, entre otras tareas de IT.
+Algunos puntos a destacar son: su diseño simple orientado a que sea fácil de utilizar, el uso de OpenSSH como transporte y el diseño del lenguaje el cual el legible por humano y no requiere de conocimientos de programación. Estas características junto a que el software no tiene muchas dependencias son lo que potencian a utilizar OSA. A continuación se describirán los principales conceptos, necesarios para la utilización de Ansible:
+
+\subparagraph{Nodo de control}
+El nodo de control será quien ejecute comandos o playbooks de Ansible. Los requisitos serán tener Python instalado y Ansible. En la arquitectura utilizada, como se menciona luego en el informe, el nodo de control es el de deploy, el cual contiene los diversos scripts de Ansible y es comunica con el resto de los nodos para instalar y configurar los módulos y componentes de Openstack. Este nodo puede ser uno de los utilizados como parte del datacenter o de uso exclusivo para la instalación.
+
+\subparagraph{Inventario}
+Mantiene una lista de los nodos administrados. El inventario es un archivo en el cual se puede especificar la IP de cada nodo administrado, se pueden organizar los nodos en grupos para una mejor escalabilidad. En la siguiente sección se profundiza en este punto.
+
+\subparagraph{Módulos}
+Todas las acciones que se pueden realizar con Ansible se llevan a cabo con un módulo. Estos son las unidades de código que se ejecutan. En cada tarea se puede ejecutar uno o más módulos. Una lista completa de los módulos se encuentra en \cite{ansible-modules}.
+
+\subparagraph{Tarea}
+Es la unidad de acción en Ansible.
+
+\subparagraph{Playbook}
+Contienen una lista ordenada de tareas. Las playbooks se escriben en YAML lo cual beneficia la lectura, escritura y la comprensión de las mismas. Son una forma de organizar las tareas bajo un criterio determinado. En el caso de OSA utiliza varias playbooks para setear el ambiente inicial, instalar los componentes de infraestructura, entre otros que se especificarán en las próximas secciones.
+
+\section{Arquitectura}
+El método de instalación OSA emplea LXC para desplegar los servicios de Openstack. Además utiliza Linux bridges entre los contenedores y las interfaces físicas o lógicas del host con el fin de proveer conectividad directa a nivel de capa 2. El aislamiento de cada contenedor se logra mediante la utilización de namespaces, esto genera que se deban utilizar pares de interfaces virtuales (veth pairs) para tener conectividad entre los mismos. Esta implementación se puede ver en la imagen \ref{network-components}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.6\columnwidth]{network-components}
+ \caption{Componentes de red en Openstack. \cite{openstack-container-networking}.}
+ \label{network-components}
+\end{figure}
+
+\subsection{Arquitectura de red}
+OSA soporta múltiples arquitecturas de red, las cuales se diferencian según sea para un ambiente de producción o testing, cantidad de interfaces físicas de los servidores o módulos de openstack utilizados. Para los ambientes de producción es común utilizar interfaces bondeadas mejorando la disponibilidad de los servicios. En general para segmentar el tráfico, tanto en los casos donde se realiza bonding o en donde hay interfaces simples, se utilizan VLANs asignando un ID para cada subred utilizada dentro de Openstack. A continuación se describen las subredes empleadas por OSA para su funcionamiento:
+
+\subparagraph{Management Network}
+La red de administración o también container network se encarga de proveer la administración y comunicación entre la infraestructura y los servicios de Openstack en containers o en servidores físicos. Para que todas las instancias tengan acceso a esta red, es necesario que todos los nodos host del datacenter cuenten con el bridge br-mgmt. A este último se le asocian las interfaces virtuales de cada contenedor y la lógica o física del host en cuestión, asignadas a dicha red. Esta interfaz suele ser la primaria del nodo mediante la cual se accede por SSH.
+
+\subparagraph{Overlay Network}
+La red de superposición o también tunnel network, provee conectividad entre los hosts virtualizados dentro de Openstack encapsulando el tráfico con algún protocolo de tunelización como son VXLAN o GENEVE. La VLAN o interfaz utilizada para esta subred se asocia al bridge br-vxlan. Este bridge debe instanciarse en todos los nodos que manejen agentes del módulo Neutron, típicamente involucra los nodos de cómputo y/o red.
+
+\subparagraph{Storage Network}
+La red de almacenamiento provee acceso entre los backends de almacenamiento, tales como Block storage, y los servicios de Openstack, como Cinder o Glance. En este caso las interfaces o VLANs se asocian al bridge br-storage, que debe instanciarse en todos los nodos que alojan servicios de cómputo o almacenamiento.
+
+\subsubsection{Interfaces de red}
+Como se mencionó en OSA se pueden tener diversas configuraciones dependiendo de la cantidad de interfaces del host físico, algunas de ellas se muestran a continuación.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{interfaces}
+ \caption{Diagrama de múltiples interfaces de red. Extraída de \cite{openstack-networking-architecture}.}
+ \label{interfaces}
+\end{figure}
+
+En la figura \ref{interfaces} se utilizan dos interfaces simples, subdivididas mediante la implementación de VLANs que finalmente se asocian a los bridges mencionados anteriormente.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{bonded-interfaces}
+ \caption{Diagrama de bonds de múltiples interfaces de red. Extraída de \cite{openstack-networking-architecture}.}
+ \label{bonded-interfaces}
+\end{figure}
+
+En el segundo, se cuenta con cuatro interfaces (provenientes de dos tarjetas físicas) que son bondeadas en forma cruzada para mejorar la disponibilidad y subdivididas mediante la implementación de VLANs para finalmente asociarlas a los bridges.\\
+
+En ambos casos, se resalta la separación de las redes tenant con las redes internas para el funcionamiento de OSA y la ausencia de veth pairs asociadas a los bridges debido a que no se visualizan servicios desplegados en contenedores. \\
+
+A continuación se presenta un diseño que ilustra servicios desplegados en contenedores y cómo varían las interconexiones de red para proveer conectividad.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{containers-deploy}
+ \caption{Despliegue de servicios Openstack en contenedores. Extraída de \cite{openstack-appendix-e}.}
+ \label{containers-deploy}
+\end{figure}
+
+Como se menciona anteriormente los contenedores que corren servicios de Openstack requieren de interfaces virtuales para conectarse con los bridges del nodo físico. Además se puede observar cómo varían las conexiones necesarias a los distintos tipos de red, en función del tipo de agente que corre en el contenedor. Al utilizar contenedores, OSA crea automáticamente una nueva red que se utilizará para la administración de los mismos (por ejemplo para descargar paquetes). Un punto a tener en cuenta es que Ansible para crear esta subred utiliza el rango 10.0.3.0/24.\\
+
+A continuación se presenta el diagrama de una arquitectura modelo de Openstack Ansible en un ambiente de producción que involucra los conceptos mencionados en puntos anteriores.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{diagrama-openstack-1}
+ \caption{Extraída de \cite{openstack-cookbook-book}}
+ \label{diagrama-openstack-1}
+\end{figure}
+
+\section{Configuración OSA}
+En esta sección se presentan las configuraciones y conceptos más relevantes del nodo Deploy a tener en cuenta durante un despliegue de Openstack utilizando Ansible. Estas incluyen las convenciones de directorios empleadas, la configuración estándar y el significado del contenido de los archivos que deben ser modificados.
+
+\subsection{Convenciones}
+\begin{itemize}
+ \item El repositorio de OSA se clona generalmente en el directorio \path{/opt/openstack-ansible}.
+ \item Los roles de Ansible utilizados por defecto se encuentran en el directorio \path{/etc/ansible/roles} los cuales son generados a partir del archivo \path{/opt/openstack-ansible/ansible-role-requirements.yml} mediante la ejecución del \path{script bootstrap-ansible.sh}.
+ \item Las configuraciones realizadas por el administrador son indicadas en el directorio \path{/etc/openstack_deploy}.
+\end{itemize}
+
+\subsection{Inventario}
+Define las especificaciones de los hosts y contenedores dentro del ambiente actual de Openstack. Esta información se encuentra en el archivo \path{/etc/openstack-ansible/openstack_inventory.json}, generado a partir de los host groups, containers groups y components indicados en:
+\begin{itemize}
+ \item La estructura por defecto almacenada en \path{/opt/openstack-ansible/inventory/env.d}
+ \item Lo configurado por el administrador dentro de \path{/etc/openstack_deploy/} en:
+ \begin{itemize}
+ \item El archivo \path{openstack_user_config.yml}
+ \item El directorio \path{conf.d/}
+ \item El directorio \path{env.d/}
+ \end{itemize}
+\end{itemize}
+
+Este archivo es considerado como referencia en cualquiera de los comandos asociados al despliegue de OSA por lo tanto nunca debe ser eliminado o modificado en un ambiente de producción.\\
+
+Los components hacen referencia a los diferentes servicios que serán instalados durante el despliegue de Openstack, tanto en contenedores virtuales como directamente en los target host. Los containers groups agrupan estos components, determinando los potenciales contenedores a ser creados junto con sus especificaciones.
+En las configuraciones realizadas en ambos directorios env.d/ se asocian los containers groups anteriores con los hosts groups, los cuales agrupan diversos target hosts. De esta forma se determina qué servicio debe ser instalado en qué target host.
+
+\subsection{openstack\_user\_config.yml}
+Es el principal archivo de configuración, creado por el operador de Openstack. Las especificaciones de cada sección se detallan en \cite{openstack-user-config}.
+
+\chapter{Instalación}
+
+\section{Diseño de arquitectura}
+A continuación se presenta un diagrama \ref{diseño-arquitectura} de la arquitectura diseñada para la instalación de Openstack Ansible. Al tratarse de un ambiente meramente de prueba, sólo se cuenta con un nodo de cada tipo definido previamente. En el mismo se puede apreciar que no se han utilizado VLANs ni bonds en las interfaces de los servidores, sino que se han agregado tantas interfaces físicas como fueran necesarias. Se detallan también las numeraciones IP a ser utilizadas en cada una de las redes necesarias y las asignaciones a los diferentes bridges de cada uno de los nodos. Cabe mencionar que la IP pública del balanceador de carga pertenece a la subred en la que se encuentra el servidor físico sobre el cual se virtualizarán todos los nodos, con el fin de tener acceso externo a la plataforma.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{dis-arquitectura}
+ \caption{Arquitectura diseñada.}
+ \label{diseño-arquitectura}
+\end{figure}
+
+El siguiente diagrama muestra la disposición de los componentes de red en la arquitectura utilizada en donde el nodo de control y red se colapsaron a uno solo:
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.6\columnwidth]{neutron3}
+ \caption{Disposición de componentes en Neutron. Extraída de \cite{openstack-networking-book-4}.}
+ \label{neutron3}
+\end{figure}
+
+
+
+\section{Ambiente de trabajo}
+
+\subsection{Hardware utilizado}
+Para realizar la instalación de Openstack se utilizó un servidor físico (denominado renata) alojado en el Instituto de Computación de la Facultad de Ingeniería (InCo). El mismo cuenta con una amplia cantidad de recursos destacando sus 40 procesadores virtuales, 128 GB de RAM y 40 TB de disco duro. Se aloja en una red privada del InCo en donde para salir a Internet se debe pasar por un proxy, provocando algunas limitaciones que luego se mencionan.\\
+
+En el servidor fueron necesarias las siguientes configuraciones de red:
+\begin{enumerate}
+ \item Creación de un bridge el cual será utilizado por la interfaz física del servidor y por los distintos NAT que se deben crear con KVM para la arquitectura que se virtualiza.
+Para esto se creo la interfaz br-mgmt con la siguiente configuración:
+ \begin{lstlisting}
+ DEVICE="br-mgmt"
+ BOOTPROTO="none"
+ IPADDR="192.168.60.242"
+ PREFIX="24"
+ GATEWAY="192.168.60.1"
+ DNS1="192.168.60.230"
+ ONBOOT="yes"
+ TYPE="Bridge"
+ NM_CONTROLLED="no"
+ \end{lstlisting}
+
+ \item En la interfaz eno2 la cual tenía configurada la IP del bridge quedó de la siguiente forma:
+ \begin{lstlisting}
+ BOOTPROTO=none
+ NAME=eno2
+ UUID=824cd835-662a-4d47-a148-512aec3dd237
+ DEVICE=eno2
+ ONBOOT=yes
+ BRIDGE="br-mgmt"
+ NM_CONTROLLED="no"
+ \end{lstlisting}
+\end{enumerate}
+
+\subsection{Conexión remota hacia el servidor renata}
+Dado que el servidor se encuentra en una red privada del InCo, para conectarse al mismo de forma remota se deben establecer algunas conexiones SSH. A continuación se detallan las conexiones y comandos utilizados.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{acceso-renata}
+ \caption{Acceso remoto al servidor renata.}
+ \label{acceso-renata}
+\end{figure}
+
+\begin{enumerate}
+ \item Como el servidor se encuentra en una red privada del InCo solo se puede acceder desde un host que se encuentre en una red interna de la FIng, por ej: lulu.fing.edu.uy. Para esto ejecutar:
+ \begin{lstlisting}
+ $ ssh usuario_fing@lulu.fing.edu.uy
+ \end{lstlisting}
+
+ \item Desde el host lulu para conectarse al servidor renata se debe ejecutar:
+ \begin{lstlisting}
+ $ ssh openstack@192.168.60.242
+ \end{lstlisting}
+\end{enumerate}
+
+\subsection{Virtualización con KVM}
+Para crear la arquitectura de nodos se utilizó el virtualizador KVM, debido a que es la tecnología de virtualización utilizada normalmente en los servidores del InCo. Con el fin de facilitar la interacción con KVM a través de una interfaz gráfica, se utilizó el programa virt-manager.
+
+\subsubsection{Utilización virt-manager}
+Dentro del virt-manager lo primero a realizar es configurar una nueva conexión desde el menú Archivo -> Añadir conexión... de la siguiente forma:
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-nueva-conexion}
+ \caption{Nueva conexión en virt-manager.}
+ \label{virt-nueva-conexion}
+\end{figure}
+
+Como un host remoto está a dos conexiones SSH del servidor Renata, la configuración que se muestra en la figura X no será suficiente. Para el correcto funcionamiento se debe crear una regla de forwarding que envíe todas las acciones realizadas por el virt-manager hacia el host lulu.fing.edu.uy el cual tiene acceso al servidor. Para lograr esto se debe ejecutar:
+
+\begin{lstlisting}[gobble=0]
+ssh -L 5900:192.168.60.242:22 <usuario_fing>@lulu.fing.edu.uy
+\end{lstlisting}
+
+El número de puerto utilizado puede ser cualquiera que no esté siendo utilizado y no sea privilegiado.\\
+
+El orden adecuado para conectarse al servidor mediante virt-manager es:
+
+\begin{enumerate}
+ \item Crear la conexión ssh indicada.
+ \item Iniciar virt-manager.
+ \item Inicializar la conexión. En este paso se puede llegar a requerir la contraseña del usuario del servidor renata desde la consola que esté ejecutando el manager.
+\end{enumerate}
+
+Lo siguiente a realizar es crear con KVM las redes virtuales que se natean al bridge br-mgmt del servidor físico. Es necesario crear 4 redes, donde cada una se corresponde con las redes necesarias para el funcionamiento de Openstack. Estas redes son:
+
+\begin{itemize}
+ \item NAT-Open (Red management Subred 10.0.1.0/24).
+ \item NAT-Open-Storage (Red storage Subred 10.0.10.0/24).
+ \item NAT-Open-Vxlan (Red vxlan Subred 10.0.2.0/24).
+ \item NAT-Open-Vlan (Red vlan Subred 10.0.4.0/24).
+\end{itemize}
+
+Para crear estas redes se debe ir al menú Editar -> Detalles de la conexión.
+Luego como se muestra en la imagen en la pestaña de redes virtuales seleccionar el icono (+).
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-conf-red}
+ \caption{Configuración de redes virtuales en virt-manager.}
+ \label{virt-conf-red}
+\end{figure}
+
+Al presionar el botón para agregar un nueva red, desplegará en pantalla un wizard. A continuación se muestra el paso a paso de la creación de la red NAT-Open a modo de ejemplo:
+
+\begin{enumerate}
+ \item Seleccionar el nombre de la red
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-red-1}
+ \label{virt-red-1}
+\end{figure}
+
+ \item Seleccionar la subred y el rango para el DHCP
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-red-2}
+ \label{virt-red-2}
+\end{figure}
+
+ \item No habilitar direcciones IPv6
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-red-3}
+ \label{virt-red-3}
+\end{figure}
+
+ \item Seleccionar el tipo de red virtual
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-red-4}
+ \label{virt-red-4}
+\end{figure}
+
+\end{enumerate}
+
+El mismo procedimiento se deberá repetir con el resto de las redes listadas.\\
+
+Lo último que es necesario crear con KVM son las nodos virtuales que se utilizaron para instalar Openstack. En la instalación realizada se utilizan 5 nodos con las especificaciones detalladas a continuación:
+
+\begin{itemize}
+ \item \textbf{Nodo deploy}:
+ \begin{itemize}
+ \item 1 interfaz en NAT-Open
+ \item 2 CPUs
+ \item 200 GB de disco
+ \item 8 GB de RAM
+ \end{itemize}
+
+ \item \textbf{Nodo haproxy1}:
+ \begin{itemize}
+ \item 2 interfaces: una en NAT-Open y otra conectada al bridge br-mgmt de renata
+ \item 4 CPUs
+ \item 200 GB de disco
+ \item 32 GB de RAM
+ \end{itemize}
+
+ \item \textbf{Nodo infra1}:
+ \begin{itemize}
+ \item 4 interfaces: una en cada NAT creada
+ \item 8 CPUs
+ \item 200 GB de disco
+ \item 32 GB de RAM
+ \end{itemize}
+
+ \item \textbf{Nodo compute1}:
+ \begin{itemize}
+ \item 4 interfaces: una en cada NAT creada
+ \item 8 CPUs
+ \item 200 GB de disco
+ \item 32 GB de RAM
+ \end{itemize}
+
+ \item \textbf{Nodo storage1}:
+ \begin{itemize}
+ \item 2 interfaces: una en NAT-Open y otra en NAT-Open-Storage
+ \item 4 CPUs
+ \item 2 discos: uno de 40 GB para el SO y otro de 200 GB para el volumen de cinder
+ \item 32 GB de RAM
+ \end{itemize}
+
+\end{itemize}
+
+A continuación se detalla paso a paso cómo crear el nodo deploy, el resto se realiza de forma análoga salvando las diferencias de recursos e interfaces de red.
+
+\begin{enumerate}
+ \item En el presente ejemplo se crea una VM suponiendo que se instalará el SO.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-nodo-1}
+ \label{virt-nodo-1}
+\end{figure}
+
+ \item Seleccionar la imagen a utilizar y el tipo de SO. La misma deberá estar en un directorio del servidor físico.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{virt-nodo-2}
+ \label{virt-nodo-2}
+\end{figure}
+
+ \item Seleccionar RAM y CPUs.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-nodo-3}
+ \label{virt-nodo-3}
+\end{figure}
+
+ \item Para el almacenamiento se deberá crear un nuevo volumen de la siguiente forma:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Elegir la segunda opción y presionar Administrar.
+ \begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{virt-nodo-4a}
+ \label{virt-nodo-4a}
+ \end{figure}
+
+ \item Esto desplegará una ventana mostrando directorios del sistema de archivos de renata. Se puede elegir un volumen existente o crear uno nuevo con el botón (+).
+ \begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{virt-nodo-4b}
+ \label{virt-nodo-4b}
+ \end{figure}
+
+ \item Al crearlo se debe especificar el nombre, el tipo y la capacidad.
+ \begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{virt-nodo-4c}
+ \label{virt-nodo-4c}
+ \end{figure}
+
+ \end{enumerate}
+
+ \item Luego se debe ingresar el nombre de la máquina y seleccionar la red que conecta el host directamente al bridge del servidor físico en lugar de la red NAT-Open para que el host tenga conexión a internet durante la instalación y poder realizar las primeras configuraciones en el mismo.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.6\columnwidth]{virt-nodo-5}
+ \label{virt-nodo-5}
+\end{figure}
+
+ \item Se debe verificar en la opción IDE CDROM 1 que esté correctamente seteado la imagen a utilizar para instalar el SO.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{virt-nodo-6}
+ \label{virt-nodo-6}
+\end{figure}
+
+ \item Verificar en las opciones de arranque que el IDE CDROM 1 esté en primer lugar para que la máquina bootee con la imagen seleccionada.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{virt-nodo-7}
+ \label{virt-nodo-7}
+\end{figure}
+
+ \item Finalmente al confirmar todos los cambios se lanzará la VM creada y se instalará el SO.
+
+\end{enumerate}
+
+\subsection{Especificaciones servidor renata}
+La red en la que se encuentra el servidor Renata no cuenta con acceso a internet. Para solucionar este problema se realizó un túnel ssh reverso desde el host lulu.fing.edu.uy al servidor Renata para establecer como proxy de Renata el host proxy.fing.edu.uy, siendo este último el proxy de la FING.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{redes-renata}
+ \caption{Túnel reverso y esquema de servidores.}
+ \label{redes-renata}
+\end{figure}
+
+El funcionamiento de esta configuración se detalla a continuación:
+
+\begin{itemize}
+ \item El host lulu.fing.edu.uy inicia una conexion SSH con renata en donde indica que cree una conexión inversa con el proxy de la FIng.
+
+ \item Al establecer la conexión, el servidor renata crea el túnel inverso en donde envía todos los paquetes destinados al puerto 3128 al servidor proxy en el puerto 3128.
+
+ \item Finalmente para que renata tenga acceso a Internet se setean las variables de entorno http\_proxy y https\_proxy con el valor http://localhost:3128. De esta forma todo el tráfico http será enviado al puerto 3128 local y gracias al túnel reverso todos los pedidos http serán enviados al proxy logrando tener acceso a Internet.
+\end{itemize}
+
+Para lograr esto se debe ejecutar el siguiente comando al iniciar la conexión SSH desde lulu hacia renata:
+
+\begin{lstlisting}[gobble=0]
+$ ssh -R 3128:proxy.fing.edu.uy:3128 openstack@192.168.60.242
+\end{lstlisting}
+
+Como se muestra en la figura \ref{redes-renata} el servidor DNS utilizado se encuentra en la misma red local.
+
+\subsection{Acceso al exterior desde nodos}
+Los nodos virtualizados en el servidor renata con la configuración por defecto no tendrán acceso a Internet. Esto sucede por que al realizar un pedido http o https será enviado al gateway de estos nodos virtuales que es la IP 10.0.1.1 de la interfaz virtual de renata, en donde solamente forwardea los paquetes recibidos en el puerto 3128 al proxy de la FIng. Para solucionar esto basta con configurar las variables de entorno http\_proxy y https\_proxy en los nodos virtualizados con el siguiente valor: http://10.0.1.1:3128. Esto aplica para los 5 nodos utilizados en la instalación.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.0\columnwidth]{internet-nodos}
+ \caption{Salida a Internet en los nodos de Openstack.}
+ \label{internet-nodos}
+\end{figure}
+
+% ------------------------------------------------------
+
+\section{Preparación de nodos}
+En la siguiente sección se detallan los pasos necesarios a seguir en cada uno de los nodos para iniciar con la instalación de Openstack.
+Para realizar dicha configuración inicial será necesario que los nodos cuenten con conexión a internet. En el ambiente de trabajo actual, esto es equivalente a verificar que las variables del proxy estén bien configuradas.
+
+\subsubsection{Deploy}
+\begin{enumerate}
+ \item Configurar la interfaz de red eth0 de la siguiente forma:
+ \begin{lstlisting}
+ TYPE=Ethernet
+ BOOTPROTO=none
+ DEFROUTE=yes
+ NAME=eth0
+ DEVICE=eth0
+ ONBOOT=yes
+ IPADDR=10.0.1.10
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ \end{lstlisting}
+
+ \item Asociar, en el virt-manager, la interfaz de red eth0 a la red virtual de management 10.0.1.0/24.
+ \begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{virt-manager-eth0}
+ \caption{}
+ \label{virt-manager-eth0}
+ \end{figure}
+
+ \item Por simplificación , cambiar el hostname de la máquina a ‘deploy’ con el comando:
+ \begin{lstlisting}
+ $ hostname deploy
+ \end{lstlisting}
+
+ \item Configurar las variables de proxy en \path{/etc/environment} con los siguientes comandos:
+ \begin{lstlisting}
+ $ echo "http_proxy=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "https_proxy=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "HTTP_PROXY=http://10.0.1.1:3128" >> /etc/environment
+ $ echo "HTTPS_PROXY=http://10.0.1.1:3128" >> /etc/environment
+ $ source /etc/environment
+ \end{lstlisting}
+
+ Verificar el acceso a internet mediante el comando:
+ \begin{lstlisting}
+ $ curl www.google.com.
+ \end{lstlisting}
+
+ \item Instalaciones necesarias:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Actualizar repositorios y reiniciar:
+ \begin{lstlisting}[gobble=8]
+ $ yum upgrade -y
+ $ reboot
+ \end{lstlisting}
+ \item Instalar repositorio openstack queens:
+ \begin{lstlisting}[gobble=8]
+ $ yum install -y https://rdoproject.org/repos/openstack-queens/rdo-release-queens.rpm
+ \end{lstlisting}
+ \item Instalar herramientas auxiliares:
+ \begin{lstlisting}[gobble=8]
+ $ yum install -y git ntp nano net-tools ntpdate openssh-server python-devel sudo '@Development Tools'
+ \end{lstlisting}
+ \end{enumerate}
+
+ \item Deshabilitar firewall de CentOS:
+ \begin{lstlisting}
+ $ systemctl stop firewalld
+ $ systemctl mask firewalld
+ \end{lstlisting}
+
+ \item Configurar el servicio de NTP mediante Chrony, sustituyendo en el archivo \path{/etc/chrony.conf} las siguientes líneas:
+ \begin{lstlisting}
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+ \end{lstlisting}
+
+ Reiniciar el servicio mediante:
+ \begin{lstlisting}
+ $ systemctl restart chronyd
+ \end{lstlisting}
+
+ \item Clonar el repositorio de Openstack Ansible Queens
+ \begin{lstlisting}
+ $ git clone -b 17.1.10 https://git.openstack.org/openstack/openstack-ansible /opt/openstack-ansible
+ \end{lstlisting}
+
+ \item Preparar openstack-ansible:
+ \begin{lstlisting}
+ $ /opt/openstack-ansible/scripts/bootstrap-ansible.sh
+ \end{lstlisting}
+ Este script se utiliza para asegurar que Ansible y todas las dependencias necesarias para la instalación de OSA están instaladas en el nodo de deploy.
+
+ \item Copiar el contenido de configuración al \path{/etc}:
+ \begin{lstlisting}
+ $ cp -r /opt/openstack-ansible/etc/openstack_deploy /etc/
+ \end{lstlisting}
+
+ \item Crear la carpeta para logs de la instalación:
+ \begin{lstlisting}
+ $ mkdir /var/log/openstack
+ \end{lstlisting}
+
+\end{enumerate}
+
+\subsubsection{Infra1}
+\begin{enumerate}
+ \item Configuraciones de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Configurar los bridges br-mgmt, br-storage y br-vxlan.
+ \begin{multicols}{3}
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-mgmt
+ BOOTPROTO=none
+ IPADDR=10.0.1.11
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-storage
+ BOOTPROTO=none
+ IPADDR=10.0.2.11
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-vxlan
+ BOOTPROTO=none
+ IPADDR=10.0.10.11
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \item Configurar las interfaces eth0, eth1, eth2 y eth3.
+ \begin{multicols}{4}
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth0
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-mgmt
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth1
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-storage
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth2
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-vxlan
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth3
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \end{enumerate}
+
+ \item Asociar, en el virt-manager, las interfaces de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item eth0 a la red virtual de management 10.0.1.0/24.
+ \item eth1 a la red virtual de storage 10.0.2.0./24.
+ \item eth2 a la red virtual de vxlan 10.0.10.0./24.
+ \item eth3 a la red virtual de vlan 10.0.4.0./24.
+ \end{enumerate}
+
+ \item Cambiar el hostname de la máquina a ‘infra1’ con el comando:
+ \begin{lstlisting}
+ $ hostname infra1
+ \end{lstlisting}
+
+ \item Configurar las variables de proxy en la sesión pero no en el sistema, porque luego el nodo deploy configura el \path{/etc/environment} en todos los nodos.
+ \begin{lstlisting}
+ $ export http_proxy=http://10.0.1.1:3128
+ $ export https_proxy=http://10.0.1.1:3128
+ $ export HTTP_PROXY=http://10.0.1.1:3128
+ $ export HTTPS_PROXY=http://10.0.1.1:3128
+ \end{lstlisting}
+
+ Verificar el acceso a internet mediante el comando:
+ \begin{lstlisting}
+ $ curl www.google.com
+ \end{lstlisting}
+
+ \item Actualizar repositorios y reiniciar:
+ \begin{lstlisting}
+ $ yum upgrade -y
+ $ reboot
+ \end{lstlisting}
+
+ \item Instalar herramientas auxiliares:
+ \begin{lstlisting}
+ $ yum install bridge-utils iputils lsof lvm2 ntp ntpdate openssh-server sudo tcpdump python net-tools nano
+ \end{lstlisting}
+
+ \item Deshabilitar el Network Manager:
+ \begin{lstlisting}
+ $ chkconfig NetworkManager off
+ $ chkconfig network on
+ $ service NetworkManager stop
+ $ service network start
+ \end{lstlisting}
+
+ \item Deshabilitar el SELinux, cambiando en \path{/etc/sysconfig/selinux}, "SELINUX=enforcing" por "SELINUX=disabled".
+
+ \item Habilitar bonding de interfaces y vlans:
+ \begin{lstlisting}
+ $ echo 'bonding' >> /etc/modules-load.d/openstack-ansible.conf
+ $ echo '8021q' >> /etc/modules-load.d/openstack-ansible.conf
+ \end{lstlisting}
+
+ \item Configurar el servicio de NTP mediante Chrony, sustituyendo en el archivo \path{/etc/chrony.conf} las siguientes líneas:
+ \begin{lstlisting}
+ server 0.south-america.pool.ntp.org
+ server 1.south-america.pool.ntp.org
+ server 2.south-america.pool.ntp.org
+ server 3.south-america.pool.ntp.org
+ \end{lstlisting}
+
+ Reiniciar el servicio mediante:
+ \begin{lstlisting}
+ $ systemctl restart chronyd
+ \end{lstlisting}
+
+ \item Eliminar reglas de firewall que bloquean el tráfico:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Eliminar las reglas manualmente:
+ \begin{lstlisting}[gobble=8]
+ $ iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
+ $ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
+ \end{lstlisting}
+
+ \item Exportar las reglas a un archivo:
+ \begin{lstlisting}[gobble=8]
+ $ iptables-save > /etc/sysconfig/iptables
+ \end{lstlisting}
+
+ \item En cada reboot de la máquina, importar las reglas del archivo anterior:
+ \begin{lstlisting}[gobble=8]
+ $ iptables-restore < /etc/sysconfig/iptables
+ \end{lstlisting}
+
+ \end{enumerate}
+
+\end{enumerate}
+
+\subsubsection{Compute1}
+\begin{enumerate}
+ \item Configuraciones de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Configurar los bridges br-mgmt, br-storage y br-vxlan.
+ \begin{multicols}{3}
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-mgmt
+ BOOTPROTO=none
+ IPADDR=10.0.1.12
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-storage
+ BOOTPROTO=none
+ IPADDR=10.0.2.12
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-vxlan
+ BOOTPROTO=none
+ IPADDR=10.0.10.12
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \item Configurar las interfaces eth0, eth1, eth2 y eth3.
+ \begin{multicols}{4}
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth0
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-mgmt
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth1
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-storage
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth2
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-vxlan
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth3
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \end{enumerate}
+
+ \item Asociar, en el virt-manager, las interfaces de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item eth0 a la red virtual de management 10.0.1.0/24.
+ \item eth1 a la red virtual de storage 10.0.2.0./24.
+ \item eth2 a la red virtual de vxlan 10.0.10.0./24.
+ \item eth3 a la red virtual de vlan 10.0.4.0./24.
+ \end{enumerate}
+
+ \item Cambiar el hostname de la máquina a 'compute1' con el comando:
+ \begin{lstlisting}
+ $ hostname compute1
+ \end{lstlisting}
+
+\end{enumerate}
+
+A partir de este punto, el procedimiento es idéntico al nodo infra1. Se deben realizar los puntos 4 al 11.
+
+\subsubsection{Storage1}
+\begin{enumerate}
+ \item Configuraciones de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Configurar los bridges br-mgmt y br-storage.
+ \begin{multicols}{2}
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-mgmt
+ BOOTPROTO=none
+ IPADDR=10.0.1.13
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ DEVICE=br-storage
+ BOOTPROTO=none
+ IPADDR=10.0.2.13
+ PREFIX=24
+ ONBOOT=yes
+ TYPE=Bridge
+ NM_CONTROLLED=no
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \item Configurar las interfaces eth0 y eth1.
+ \begin{multicols}{2}
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth0
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-mgmt
+ \end{lstlisting}
+
+ \columnbreak
+
+ \begin{lstlisting}[gobble=16]
+ TYPE="Ethernet"
+ BOOTPROTO=none
+ DEVICE=eth1
+ ONBOOT=yes
+ NM_CONTROLLED=no
+ BRIDGE=br-storage
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \end{enumerate}
+
+ \item Asociar, en el virt-manager, las interfaces de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item eth0 a la red virtual de management 10.0.1.0/24.
+ \item eth1 a la red virtual de storage 10.0.2.0./24.
+ \end{enumerate}
+
+ \item Cambiar el hostname de la máquina a 'storage1' con el comando:
+ \begin{lstlisting}
+ $ hostname storage1
+ \end{lstlisting}
+
+\end{enumerate}
+
+A partir de este punto, el procedimiento es idéntico al nodo infra1. Se deben realizar los puntos 4 al 11.
+
+\begin{enumerate}
+ \setcounter{enumi}{11}
+
+ \item Crear el volumen de LVM para utilizar Cinder:
+ \begin{enumerate}[label*=\arabic*.]
+ \item Listar los devices en la máquina:
+ \begin{lstlisting}[gobble=8]
+ $ lvmdiskscan
+ \end{lstlisting}
+
+ \item Formatear la pieza física de almacenamiento de 200 GB:
+ \begin{lstlisting}[gobble=8]
+ $ pvcreate --metadatasize 2048 physical_volume_device_path
+ \end{lstlisting}
+
+ \item Crear el nuevo grupo de almacenamiento que será utilizado por Openstack:
+ \begin{lstlisting}[gobble=8]
+ $ vgcreate cinder-volumes physical_volume_device_path
+ \end{lstlisting}
+
+ \item Verificar que el grupo quedó creado correctamente:
+ \begin{lstlisting}[gobble=8]
+ $ vgdisplay
+ \end{lstlisting}
+
+ \end{enumerate}
+
+\end{enumerate}
+
+\subsubsection{HAproxy1}
+\begin{enumerate}
+ \item Configurar las interfaces eth0 y eth1.
+ \begin{multicols}{2}
+ \begin{lstlisting}[gobble=8]
+ TYPE=Ethernet
+ BOOTPROTO=none
+ DEFROUTE=yes
+ DEVICE=eth0
+ ONBOOT=yes
+ IPADDR=10.0.1.15
+ PREFIX=24
+ GATEWAY=10.0.1.1
+ DNS1=192.168.60.230
+ \end{lstlisting}
+
+ \columnbreak
+ \begin{lstlisting}[gobble=8]
+ TYPE=Ethernet
+ BOOTPROTO=none
+ DEFROUTE=yes
+ DEVICE=eth1
+ ONBOOT=yes
+ IPADDR=192.168.60.160
+ PREFIX=24
+ \end{lstlisting}
+
+ \end{multicols}
+
+ \item Asociar, en el virt-manager, las interfaces de red:
+ \begin{enumerate}[label*=\arabic*.]
+ \item eth0 a la red virtual de management 10.0.1.0/24.
+ \item eth1 al bridge alojado en el servidor renata en la red 192.168.60.0/24.
+ \end{enumerate}
+
+ \item Cambiar el hostname de la máquina a 'haproxy1' con el comando:
+ \begin{lstlisting}
+ $ hostname haproxy1
+ \end{lstlisting}
+
+\end{enumerate}
+
+A partir de este punto, el procedimiento es similar al nodo infra1. Se deben realizar los puntos 4 al 11 con la excepción del punto 7 en donde se deshabilita el NetworkManager.
+
+\section{Configuración}
+Luego de completar la preparación de los nodos y verificar la conectividad entre los mismos, los últimos pasos antes de iniciar con la instalación de Openstack son configurar los archivos que OSA utiliza y los requerimientos extras de la herramienta utilizada para la instalación.
+
+\subsection{Configuración claves SSH}
+Como se menciona en la sección de Ansible, el nodo de deploy requiere de una conexión SSH con cada uno de los servidores que componen el datacenter, para poder configurar y operar directamente sobre cada uno de ellos. Para esto se utilizan un par de claves SSH público-privada con el fin de brindarle al nodo de deploy mayor flexibilidad al momento de acceder a los servidores. Se deberá propagar la clave del usuario root dado que es este usuario el que llevará a cabo la instalación.
+El comando que se debe ejecutar para crear las claves es el siguiente:
+
+\begin{lstlisting}[gobble=0]
+$ ssh-keygen -t rsa -f ~/.ssh/id_rsa -N ""
+\end{lstlisting}
+
+Donde:
+\begin{itemize}
+ \item \textbf{-t}: especifica el tipo de encriptación.
+ \item \textbf{-f}: determina el archivo en donde quedará la clave privada (por defecto, la pública será igual con la extensión .pub).
+ \item \textbf{-N "}\textbf{"} indica que no se utilizará ninguna passphrase en la clave.
+\end{itemize}
+
+Esto genera dos archivos (\path{id_rsa} y \path{id_rsa.pub}) donde el primero es la clave privada (que no se deberá compartir) y el segundo la clave pública que se copiará al resto de los servidores con los siguientes comandos:
+
+\begin{lstlisting}[gobble=0]
+$ ssh-copy-id root@10.0.1.11
+$ ssh-copy-id root@10.0.1.12
+$ ssh-copy-id root@10.0.1.13
+$ ssh-copy-id root@10.0.1.15
+\end{lstlisting}
+
+Para verificar la configuración bastará con realizar un ssh a cada servidor desde el deploy con el usuario root, accediendo en forma directa al prompt de dicho servidor.
+
+\subsection{Archivos de configuración OSA}
+
+\subsubsection{openstack\_user\_config.yml}
+A continuación se detalla cada bloque de configuración utilizado en la instalación realizada.\\
+
+En la primera sección, cidr\_networks, se describen las subredes utilizadas en la instalación de Openstack.
+
+\begin{lstlisting}[gobble=0]
+cidr_networks:
+ container: 10.0.1.0/24
+ tunnel: 10.0.10.0/24
+ storage: 10.0.2.0/24
+\end{lstlisting}
+
+La red de container permite a los distintos servicios , ejecutados dentro de contenedores o servidores físicos, comunicarse entre sí. La red tunnel es utilizada cuando un usuario crea una nueva red tennant dentro de un proyecto de Openstack, en el caso que corresponda se creará una red VXLAN en este red física. Por último la red de storage la utilizaran los nodos que alojan el backend y los servicios de storage de Openstack. Los rangos elegidos son totalmente arbitrarios, a excepción de la subred 10.0.3.0/24 debido a que es utilizada internamente por OSA durante su ejecución como se mencionó en la sección de arquitectura de red.\\
+
+Lo siguiente a configurar son las direcciones IP que están siendo utilizadas por los hosts físicos de la infraestructura en las redes definidas previamente, con el fin de reservarlas y que la instalación no utilice ninguna de ellas para la estructura de Openstack.
+
+\begin{lstlisting}[gobble=0]
+used_ips:
+ - "10.0.1.1,10.0.1.20" # red de management
+ - "10.0.2.1,10.0.2.20" # red de storage
+ - "10.0.10.1,10.0.10.20" # red de vxlan
+\end{lstlisting}
+\vspace{8pt}
+En la sección global\_overrides se describen los bridges utilizados y detalles de las interfaces del ambiente, por ejemplo, cómo los containers se conectan a la red física de los hosts.
+
+\begin{lstlisting}[gobble=0]
+global_overrides:
+ internal_lb_vip_address: 10.0.1.15
+ external_lb_vip_address: 192.168.60.160
+\end{lstlisting}
+Estos parámetros refieren a las direcciones IPs pública y privada del balanceador de carga. La privada es utilizada internamente por los servicios de Openstack y la pública es la puerta de acceso para los usuarios.
+\\
+\begin{lstlisting}[gobble=0]
+ tunnel_bridge: "br-vxlan"
+ management_bridge: "br-mgmt"
+ storage_bridge: "br-storage"
+\end{lstlisting}
+
+Con estas variables se define el nombre asignado a cada uno de los bridges creados en los hosts físicos.\\
+
+La sección de provider\_networks describe la relación entre la red de los contenedores y el ambiente físico de los servidores.
+
+\begin{lstlisting}[gobble=0]
+ provider_networks:
+ - network:
+ group_binds:
+ - all_containers
+ - hosts
+ type: "raw"
+ container_bridge: "br-mgmt"
+ container_interface: "eth1"
+ container_type: "veth"
+ ip_from_q: "container"
+ is_container_address: true
+ is_ssh_address: true
+ - network:
+ group_binds:
+ - glance_api
+ - cinder_api
+ - cinder_volume
+ - nova_compute
+ type: "raw"
+ container_bridge: "br-storage"
+ container_type: "veth"
+ container_interface: "eth2"
+ container_mtu: "9000"
+ ip_from_q: "storage"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vxlan"
+ container_type: "veth"
+ container_interface: "eth10"
+ container_mtu: "9000"
+ ip_from_q: "tunnel"
+ type: "vxlan"
+ range: "1:1000"
+ net_name: "vxlan"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vlan"
+ container_type: "veth"
+ container_interface: "eth12"
+ host_bind_override: "eth3"
+ type: "flat"
+ net_name: "flat"
+\end{lstlisting}
+\vspace{8pt}
+La última sección describe en qué servidor o grupo de servidores corre cada servicio de Openstack y de infraestructura.
+
+\begin{lstlisting}[gobble=0]
+### Infrastructure
+# galera, memcache, rabbitmq, utility
+shared-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+# repository (apt cache, python packages, etc)
+repo-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+# load balancer
+# Dedicated hardware is best for improved performance and security.
+haproxy_hosts:
+ balancer1:
+ ip: 10.0.1.15
+# rsyslog server
+log_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+### OpenStack
+# keystone
+identity_hosts:
+ infra1:
+ ip: 10.0.1.11
+# cinder api services
+storage-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+# glance
+image_hosts:
+ infra1:
+ ip: 10.0.1.11
+# nova api, conductor, etc services
+compute-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+# heat
+orchestration_hosts:
+ infra1:
+ ip: 10.0.1.11
+# horizon
+dashboard_hosts:
+ infra1:
+ ip: 10.0.1.11
+# neutron server, agents (L3, etc)
+network_hosts:
+ infra1:
+ ip: 10.0.1.11
+# nova hypervisors
+compute_hosts:
+ compute1:
+ ip: 10.0.1.12
+# cinder volume hosts
+storage_hosts:
+ storage1:
+ ip: 10.0.1.13
+ container_vars:
+ cinder_backends:
+ lvm:
+ volume_backend_name: LVM
+ volume_driver: cinder.volume.drivers.lvm.LVMVolumeDriver
+ volume_group: cinder-volumes
+ iscsi_ip_address: "10.0.2.13"
+\end{lstlisting}
+\vspace{8pt}
+Particularmente se resalta, en el último punto, la configuración de cinder necesaria para desplegar un backend de almacenamiento basado en LVM.
+
+\subsubsection{user\_variables.yml}
+Debido a las limitaciones de red mencionadas anteriormente, es necesario configurar un proxy de salida que será propagado por ansible hacia todos los contenedores y hosts durante la instalación. Para esto se deben configurar las siguientes variables:
+
+\begin{lstlisting}[gobble=0]
+## Example environment variable setup:
+## This is used by apt-cacher-ng to download apt packages:
+proxy_env_url: http://10.0.1.1:3128/
+
+## (1) This sets up a permanent environment, used during and after deployment:
+no_proxy_env: "localhost,127.0.0.1,{{ internal_lb_vip_address }},{{ external_lb_vip_address }},{% for host in groups['all_containers'] %}{{ hostvars[host]['container_address'] }}{% if not loop.last %},{% endif %}{% endfor %}"
+global_environment_variables:
+ HTTP_PROXY: "{{ proxy_env_url }}"
+ HTTPS_PROXY: "{{ proxy_env_url }}"
+ NO_PROXY: "{{ no_proxy_env }}"
+ http_proxy: "{{ proxy_env_url }}"
+ https_proxy: "{{ proxy_env_url }}"
+ no_proxy: "{{ no_proxy_env }}"
+#
+## (2) This is applied only during deployment, nothing is left after deployment is complete:
+deployment_environment_variables:
+ http_proxy: "{{ proxy_env_url }}"
+ https_proxy: "{{ proxy_env_url }}"
+ no_proxy: "localhost,127.0.0.1,{{ internal_lb_vip_address }},{{ external_lb_vip_address }},{% for host in groups['keystone_all'] %}{{ hostvars[host]['container_address'] }}{% if not loop.last %},{% endif %}{% endfor %}"
+\end{lstlisting}
+
+Además, para poder crear una imagen desde el Horizon remotamente se debe agregar sobre el final del archivo la siguiente directiva:
+
+\begin{lstlisting}[gobble=0]
+horizon_images_upload_mode: "legacy"
+\end{lstlisting}
+
+Si bien en \cite{openstack-settings-reference} se menciona que el valor por defecto de esta variable es \textsl{legacy}, durante el proceso de instalación se detectó que es configurada como \textsl{direct}. La diferencia entre estos modos es que \textsl{legacy} permite subir archivos locales desde la máquina del usuario al servidor web de Horizon y luego de este hacia el módulo Glance. Por su parte \textsl{direct} evita esta sobrecarga de red y almacenamiento en el servidor web, conectado a través de una API al usuario con el módulo Glance. Sin embargo, esto último requiere de configuraciones extras como tener acceso al puerto 9292 (API de Glance) y un correcto uso de CORS.
+
+
+\subsubsection{cinder.yml}
+En caso de utilizar un backend de storage LVM se debe indicar que este debe ser deployado en metal, para esto se debe configurar el archivo \path{/etc/openstack_deploy/env.d/cinder-volume.yml} con lo siguiente:
+
+\begin{lstlisting}[gobble=0]
+container_skel:
+ cinder_volumes_container:
+ properties:
+ is_metal: true
+\end{lstlisting}
+
+\subsection{Generación de claves}
+Se deben configurar las passphrases requeridas por Openstack durante su instalación y posterior uso. Esto se alcanza mediante:
+
+\begin{lstlisting}[gobble=0]
+$ cd /opt/openstack-ansible
+$ ./scripts/pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml
+\end{lstlisting}
+
+\subsection{Correcciones}
+
+\subsubsection{SELinux}
+Durante el proceso de instalación se detectó un bug asociado a SELinux, el cual fue verificado en \cite{openstack-selinux-fix-1}. Debido a que en el proyecto OSA se dejó de mantener el uso de SELinux por falta de personal, se debió aplicar el commit indicado en \cite{openstack-selinux-fix-2} de la versión Rocky de OSA que desactiva por completo la utilización de este módulo.\\
+Concretamente el commit consiste en:
+
+\begin{itemize}
+ \item Eliminar los siguientes archivos:
+ \begin{lstlisting}
+ $ rm /etc/ansible/roles/os_nova/files/osa-nova.te
+ $ rm /etc/ansible/roles/os_nova/tasks/nova_selinux.yml
+ \end{lstlisting}
+
+ \item Modificar el archivo \path{/etc/ansible/roles/os_nova/tasks/nova_post_install.yml} eliminando las siguientes líneas:
+ \begin{lstlisting}
+ include_tasks: nova_selinux.yml
+ when:
+ - ansible_selinux.status == "enabled"
+ \end{lstlisting}
+\end{itemize}
+
+\section{Ejecución de playbooks}
+Finalmente para instalar Openstack con Ansible es necesario correr las playbooks principales del proyecto, las cuales se encuentran en el directorio \path{/opt/openstack-ansible/playbooks}.\\
+En primer lugar se ejecutan tres scripts para realizar un chequeo de sintaxis de la configuración preparada y los scripts a utilizar. Esto se realiza de la siguiente forma:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible setup-hosts.yml --syntax-check
+$ openstack-ansible setup-infrastructure.yml --syntax-check
+$ openstack-ansible setup-openstack.yml --syntax-check
+\end{lstlisting}
+\vspace{8pt}
+En caso de no tener errores, se comienza la ejecución de las playbook en el orden que se describen:
+
+\subsubsection{setup-hosts.yml}
+Esta playbook se encarga de configurar todos los hosts descritos en el archivo \path{openstack_user_config.yml}. Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible -vvv setup-hosts.yml 2>&1 | tee /var/log/openstack/hostsXX.log
+\end{lstlisting}
+
+La opción -vvv es para que la salida sea más verbosa y el final es para mostrar la salida del comando en la consola y almacenarla en un archivo de log.
+
+\subsubsection{install-haproxy.yml}
+La configuración de los balanceadores de carga es lo siguiente a realizar. Esto se puede realizar sin tener explícitamente los contenedores o servidores físicos con los servicios instalados gracias a Ansible. OSA como se mencionó en la sección del inventario, a partir de los archivos de configuración conoce exactamente cómo quedará instalado cada uno de los servicios de Openstack, por ejemplo las IPs y puertos de cada servicio.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible -vvv haproxy-install.yml 2>&1 | tee /var/log/openstack/haproxyXX.log
+\end{lstlisting}
+
+\subsubsection{setup-infrastructure.yml}
+En este paso demora un poco más que el primer setup y se encargará de construir todos los contenedores donde luego se instalarán los servicios de Openstack. Esta script además se encarga de instalar los servicios de infraestructura como son RabbitMQ o Galera DB para luego ser configurados en la playbook final.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible -vvv setup-infrastructure.yml 2>&1 | tee /var/log/openstack/infrastructureXX.log
+\end{lstlisting}
+
+\subsubsection{setup-openstack.yml}
+En este paso final es cuando se configuran todos los servicios, indicados en los archivos de configuración de OSA, de Openstack. Esta playbook es la que demora más tiempo en su ejecución, en el orden de las horas.
+Con el siguiente comando se ejecuta la playbook:
+
+\begin{lstlisting}[gobble=0]
+$ openstack-ansible -vvv setup-openstack.yml 2>&1 | tee /var/log/openstack/openstackXX.log
+\end{lstlisting}
+
+\section{Verificación}
+Luego de que la última playbook haya terminado su ejecución sin error, debemos verificar que la instalación fue exitosa. Esto se realizará de forma manual siguiendo los pasos que se indican a continuación:
+
+\begin{enumerate}
+ \item Acceder al nodo de infra1 como usuario root.
+
+ \item La instalación que realiza OSA crea contenedores de utilidad los cuales proveen de todas las herramientas desde la consola para utilizar Openstack. En primer lugar se deben listar todos los containers del nodo físico ejecutando:
+ \begin{lstlisting}
+ $ lxc-ls -f
+ \end{lstlisting}
+
+ \item El contenedor que se utiliza es el que tiene en su nombre la palabra utility, para acceder al mismo es necesario ejecutar el siguiente comando de lxc:
+ \begin{lstlisting}
+ $ lxc-attach -n <nombre_contenedor>
+ \end{lstlisting}
+
+ \item Para utilizar los servicios de Openstack es necesario enviar las credenciales del usuario que invocará a las APIs de los servicios. Esto se debe al funcionamiento de Openstack en donde cada llamada a una API debe ser validada por el módulo de keystone. Para evitar escribir las credenciales en cada comando, OSA genera un archivo llamado openrc para cargar la información del usuario como variables de entorno. El archivo se carga con el siguiente comando:
+ \begin{lstlisting}
+ $ source openrc
+ \end{lstlisting}
+
+ \item Algunos comandos que se pueden ejecutar son:
+ \begin{itemize}
+ \item Para listar usuarios:
+ \begin{lstlisting}[gobble=8]
+ $ openstack user list --os-cloud=default
+ \end{lstlisting}
+
+ \item Para listar servidores:
+ \begin{lstlisting}[gobble=8]
+ $ openstack server list
+ \end{lstlisting}
+
+ \item Para listar redes:
+ \begin{lstlisting}[gobble=8]
+ $ openstack network list
+ \end{lstlisting}
+
+ \item Para listar los agentes de red:
+ \begin{lstlisting}[gobble=8]
+ $ openstack network agent list
+ \end{lstlisting}
+
+ \end{itemize}
+
+ \item Por otro lado se puede verificar el dashboard de horizon accediendo a la ip definida en \path{external_lb_vip_address} en el archivo \path{/etc/openstack_deploy/openstack_user_config.yml} en el puerto 443 dado que utiliza HTTPS. Para autenticarse como admin en necesaria la password que se encuentra definida en la opción \path{keystone_auth_admin_password} del archivo \path{/etc/openstack_deploy/user_secrets.yml}.
+
+\end{enumerate}
+
+\chapter{Interaccción}
+Esta sección se realizó utilizando el dashboard de Openstack, brindado por el módulo Horizon. Debido a las limitaciones de red ya mencionadas, es necesario realizar un reenvío de puertos mediante SSH para acceder al mismo. Esto se logra en dos pasos mediante:
+
+\begin{enumerate}
+ \item Primero se realiza un forwarding desde la máquina local hasta lulu:
+ \begin{lstlisting}
+ $ ssh -L 2443:localhost:2443 <usuario_fing>@lulu.fing.edu.uy
+ \end{lstlisting}
+
+ \item Una vez dentro de lulu, se realiza un nuevo forwarding desde la misma hasta la IP pública de el balanceador, a través del servidor renata.
+ \begin{lstlisting}
+ $ ssh -L 2443:192.168.60.160:443 openstack@192.168.60.242 -4
+ \end{lstlisting}
+
+\end{enumerate}
+
+Luego, accediendo a través de un navegador a la dirección https://localhost:2443 se llega a la vista de login de Openstack.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.5\columnwidth]{openstack-login}
+ \caption{Vista del login de Horizon.}
+ \label{openstack-login}
+\end{figure}
+
+Una vez allí, se debe acceder con la cuenta de administrador para realizar las configuraciones iniciales utilizando las credenciales indicadas en el último paso de la sección de verificación.
+
+\section{Configuraciones de administrador}
+Para que los usuarios finales puedan operar sobre la plataforma Openstack, se deben configurar ciertos aspectos como lo son proyectos, usuarios, flavors y redes provider, entre otros. A continuación se presenta un instructivo básico para ello.
+
+\subsubsection{Crear proyecto}
+Lo primero a configurar es crear un proyecto sobre el cual se realizarán las pruebas siguientes. Para ello en el menú lateral se accede a Identity > Projects > Create Project, completando los campos como se muestra en la figura \ref{openstack-create-project}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-project}
+ \caption{Creación de un proyecto (1/2).}
+ \label{openstack-create-project}
+\end{figure}
+
+Antes de confirmar la creación, en la pestaña Project Members agregamos al admin como miembro del proyecto.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-project-2}
+ \caption{Creación de un proyecto (2/2).}
+ \label{openstack-create-project-2}
+\end{figure}
+
+\subsubsection{Crear usuario}
+Luego se crea un usuario de pruebas accediendo nuevamente por la pestaña lateral a Identity > Users > Create User, rellenando los campos solicitados como se presenta en la figura \ref{openstack-create-user}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-user}
+ \caption{Creación de un usuario.}
+ \label{openstack-create-user}
+\end{figure}
+
+Por más detalles se puede visitar \cite{openstack-projects-users}.
+
+\subsubsection{Crear flavor}
+El siguiente paso será crear un flavor de pruebas con algunas características básicas y permitirle acceso al proyecto de test creado. Se accede desde Admin > Compute > Flavors. Esto se ilustra en las figuras \ref{openstack-create-flavor} y \ref{openstack-create-flavor-2}. Más detalles en \cite{openstack-manage-flavors}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-flavor}
+ \caption{Creación de un flavor (1/2).}
+ \label{openstack-create-flavor}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-flavor-2}
+ \caption{Creación de un flavor (2/2).}
+ \label{openstack-create-flavor-2}
+\end{figure}
+
+\subsubsection{Crear provider network}
+Este tipo de red es manejado por los administradores y para crearlas se debe acceder a Admin > Network > Networks > Create Network, completando el formulario como se muestra en las imágenes \ref{openstack-create-provider-network-1} y \ref{openstack-create-provider-network-2}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-provider-network-1}
+ \caption{Creación de una red provider (1/2).}
+ \label{openstack-create-provider-network-1}
+\end{figure}
+
+l valor del campo Physical Network es el especificado en la red de tipo “flat” en la seccion de provider networks del archivo \path{openstack_user_config.yml}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-provider-network-2}
+ \caption{Creación de una red provider (2/2).}
+ \label{openstack-create-provider-network-2}
+\end{figure}
+
+\section{Interacción de un usuario}
+A partir de ahora, el ambiente se encuentra con las configuraciones mínimas necesarias para que el usuario test pueda acceder y hacer uso de la plataforma. Por lo tanto, los pasos a continuación se realizan sobre el proyecto de prueba, habiéndose autenticado previamente con el usuario test.
+
+\subsubsection{Crear imagen}
+Lo primero que deberá hacer el usuario para crear una instancia es crear la imagen que será utilizada por esta. Desde \cite{openstack-obtain-images} se pueden descargar formatos de imágenes soportados por Openstack de la mayoría de los sistemas operativos Linux. La creación de la imagen se realiza desde el menú Project > Compute > Images > Create Image.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-image-1}
+ \caption{Creación de una imagen (1/2).}
+ \label{openstack-create-image-1}
+\end{figure}
+
+En la primer pantalla se establecen los datos básicos para la creación de la imagen y en la siguiente se puede establecer medatada más específica de la misma.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-image-2}
+ \caption{Creación de una imagen (2/2).}
+ \label{openstack-create-image-2}
+\end{figure}
+
+\subsubsection{Crear red}
+La creación de nuevas subredes se realiza accediendo a Project > Network > Networks > Create Network. Esta funcionalidad consta de tres pasos detallados a continuación:
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-network-1}
+ \caption{Creación de una red (1/3).}
+ \label{openstack-network-image-1}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-network-2}
+ \caption{Creación de una red (2/3).}
+ \label{openstack-network-image-2}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-network-3}
+ \caption{Creación de una red (3/3).}
+ \label{openstack-network-image-3}
+\end{figure}
+
+\subsubsection{Crear router}
+La creación de nuevos routers se realiza accediendo a Project > Network > Routers > Create Router.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.7\columnwidth]{openstack-create-router}
+ \caption{Creación de un router.}
+ \label{openstack-network-router}
+\end{figure}
+
+Más detalles de estas configuraciones se pueden encontrar en \cite{openstack-manage-networks}.
+
+\subsubsection{Crear interfaz de router}
+Ir a Network > Routers y en la grilla desplegada seleccionar el router. En la pestaña de Interfaces se encuentra la opción para crear una nueva interfaz.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.7\columnwidth]{openstack-create-router-interface}
+ \caption{Creación de una interfaz en un router.}
+ \label{openstack-network-router-interface}
+\end{figure}
+
+Para la creación de una interfaz se debe ingresar la subred a la que estará conectada y opcionalmente la IP de la misma.
+
+\subsubsection{Crear key pair}
+La creación de key pairs se realiza en Project > Compute >Key Pairs > Create Key Pair.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{openstack-create-key-pair}
+ \caption{Creación de una key pair.}
+ \label{openstack-network-key-pair}
+\end{figure}
+
+Luego al momento de crear una nueva instancia se debe seleccionar una clave. Se debe tener en cuenta que la asignación de key pairs a las instancias mediante Horizon solamente se puede realizar en el momento de creación de las mismas. Más detalles se encuentran en \cite{openstack-security-instances}.
+
+\subsubsection{Lanzar una instancia}
+La creación de nuevas instancias se realiza en Project > Instances > Launch Instance.
+En primer lugar se especifican aspectos básicos como el nombre y la descripción \ref{openstack-launch-instance-1}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{openstack-launch-instance-1}
+ \caption{Lanzar una nueva instancia (1/5).}
+ \label{openstack-launch-instance-1}
+\end{figure}
+
+Luego se deberá indicar la imagen a ser utilizada para bootear la máquina. En este caso se elige la imagen imagen-test-1 creada anteriormente·
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{openstack-launch-instance-2}
+ \caption{Lanzar una nueva instancia (2/5).}
+ \label{openstack-launch-instance-2}
+\end{figure}
+
+A continuación se determinan los recursos virtuales de la instancia mediante la selección de un flavor.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{openstack-launch-instance-3}
+ \caption{Lanzar una nueva instancia (3/5).}
+ \label{openstack-launch-instance-3}
+\end{figure}
+
+El siguiente paso requerido es la selección de una red.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{openstack-launch-instance-4}
+ \caption{Lanzar una nueva instancia (4/5).}
+ \label{openstack-launch-instance-4}
+\end{figure}
+
+Finalmente, la última configuración mínimamente requerida para acceder en forma remota a la instancia es configurar una key pair.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\columnwidth]{openstack-launch-instance-5}
+ \caption{Lanzar una nueva instancia (5/5).}
+ \label{openstack-launch-instance-5}
+\end{figure}
+
+Más detalles sobre el lanzamiento de una instancia se pueden ver accediendo a \cite{openstack-manage-instances}.
+
+\section{Acceso a una instancia}
+
+\subsection{Por SPICE}
+Para acceder a la consola de la instancia creada a través del protocolo SPICE [57], es necesario dirigirse a Project > Compute > Instances > instances-test-1. Allí en la pestaña console deberíamos obtener el acceso, sin embargo debido a las limitaciones de red ya conocidas es necesario realizar un nuevo forwarding de puertos (en este caso el 6082) y acceder a través de localhost. Para esto:
+
+\begin{enumerate}
+ \item Primero se realiza un forwarding desde la máquina local hasta lulu:
+ \begin{lstlisting}
+ $ ssh -L 6082:localhost:6082 <usuario_fing>@lulu.fing.edu.uy
+ \end{lstlisting}
+
+ \item Una vez dentro de lulu, se realiza un nuevo forwarding desde la misma hasta la IP pública de el balanceador, a través del servidor renata.
+ \begin{lstlisting}
+ $ ssh -L 6082:192.168.60.160:6082 openstack@192.168.60.242 -4
+ \end{lstlisting}
+
+\end{enumerate}
+
+Luego en la pestaña de console, abrimos el link asociado a \textit{'Click here to show only console'}, esto intentará cargar en el navegador una URL similar a la siguiente:\\
+\url{https://192.168.60.160:6082/spice_auto.html?token=a3703173-3973-440d-babf-f8b662b2fd25&title=instance-test-1(430c92de-3cab-4b57-be7e-6394793dc423)}
+\\
+
+En la misma debemos sustituir la IP 192.168.60.160 por localhost para utilizar el forwarding realizado. Allí lograremos acceder a la consola SPICE.
+
+\subsection{Por SSH}
+Para lograr acceder en forma externa por SSH son necesarias algunas configuraciones extras.
+
+\subsubsection{Asociar una Floating IP a la instancia}
+Estas IPs son necesarias para poder acceder a las instancias desde redes externas. A continuación se detalla cómo realizarlo a partir de Project > Network > Floating IPs > Allocate IP To Project:
+
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-allocate-floating-ip}
+ \caption{Asignación de floating IP.}
+ \label{openstack-allocate-floating-ip}
+\end{figure}
+
+Luego se debe asociar con el puerto de la instancia creada desde Project > Network > Floating IPs > Associate.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-associate-floating-ip}
+ \caption{Asociación de floating IP.}
+ \label{openstack-associate-floating-ip}
+\end{figure}
+
+\subsubsection{Modificar security group}
+Los security groups en Openstack son firewalls virtuales en donde se definen una serie de reglas a ser aplicadas al tráfico de las instancias. El grupo creado por defecto en la instalación de Openstack contiene las siguientes reglas:
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-security-group-default}
+ \caption{Reglas security group por defecto.}
+ \label{openstack-security-group-default}
+\end{figure}
+
+Estas reglas permiten el tráfico de salida hacia cualquier IP y solamente se permite el tráfico de entrada de instancias del mismo security group.
+
+Para tener conectividad SSH e ICMP con las instancias creadas se deben agregar las siguientes reglas accediendo por Project > Network > Security Groups > Manage Rules > Add Rule.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-security-rule-icmp}
+ \caption{Agregar regla para tráfico ICMP.}
+ \label{openstack-security-group-icmp}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\columnwidth]{openstack-create-security-rule-ssh}
+ \caption{Agregar regla para tráfico SSH.}
+ \label{openstack-security-group-ssh}
+\end{figure}
+
+\subsubsection{SSH}
+Finalmente, para acceder a la consola de la instancia creada a través de SSH desde el servidor renata es necesario copiar la clave generada en el paso de key pair y luego acceder mediante:
+\begin{lstlisting}[gobble=0]
+$ ssh -i keypair-test-1.pem cirros@10.0.4.17
+\end{lstlisting}
+
+Una vez dentro, para tener conectividad a internet se debe configurar el mismo proxy que fue asignado a todos los nodos de Openstack, es decir:
+\begin{lstlisting}[gobble=0]
+$ export http_proxy="http://10.0.1.1:3128"
+\end{lstlisting}
+
+%---------------------------------------------------------------
+
+\chapter{Inconvenientes}
+
+\subsubsection{Bloqueo de paquetes}
+En los servidores virtuales y el servidor físico las reglas por defecto del firewall de CentOS bloquean tanto el tráfico utilizado para interconectar los servicios de Openstack como el empleado para las conexiones con redes externas. Para solucionar esto de forma momentánea se eliminaron estas reglas con los comandos:
+
+\begin{lstlisting}[gobble=0]
+$ iptables -D INPUT -j REJECT --reject-with icmp-host-prohibited
+$ iptables -D FORWARD -j REJECT --reject-with icmp-host-prohibited
+\end{lstlisting}
+
+\subsubsection{Módulo de seguridad SELinux}
+Como se mencionó en la sección de correcciones, OSA ha perdido el mantenimiento de este módulo de seguridad, por lo cual fue necesario aplicar los parches realizados para la siguiente versión (Rocky) a la utilizada en la instalación (Queens) para discontinuar el uso de dicho módulo.
+
+\subsubsection{Percona-release en playbook setup-infrastructure}
+Durante la instalación de la playbook mencionada se detecta el siguiente error a la hora de instalar los componentes del contenedor de galera :
+
+\begin{lstlisting}[gobble=0]
+warning: /var/cache/yum/x86_64/7/percona-release-x86_64/packages/qpress-11-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8507efa5: NOKEY
+The GPG keys listed for the \"Percona-Release YUM repository - x86_64\" repository are already installed but they are not correct for this package.
+Check that the correct key URLs are configured for this repository.
+ Failing package is: qpress-11-1.el7.x86_64
+ GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Percona
+\end{lstlisting}
+
+La solución para este problema es actualizar el paquete percona-release, dentro del contenedor de galera. Para esto se deben seguir los siguientes pasos:
+
+\begin{enumerate}
+ \item Acceder por ssh al nodo infra1
+ \begin{lstlisting}
+ $ ssh root@10.0.1.11
+ \end{lstlisting}
+
+ \item Listar los contenedores LXC existentes hasta el momento y obtener el nombre del contenedor pertinente:
+ \begin{lstlisting}
+ $ lxc-ls galera
+ \end{lstlisting}
+
+ \item Acceder a dicho contenedor:
+ \begin{lstlisting}
+ $ lxc-attach -n infra1_galera_container-15357d7d
+ \end{lstlisting}
+
+ \item Actualizar el paquete mencionado
+ \begin{lstlisting}
+ $ yum upgrade percona-release -y
+ \end{lstlisting}
+
+ \item Volver a ejecutar la playbook setup-infrastructure.
+
+\end{enumerate}
+
+\subsubsection{Subred reservada}
+Debido a que no se encuentra especificado en la documentación oficial de Openstack-Ansible, en las primeras instalaciones realizadas la subred definida para la red de tunelización (vxlan) fue la 10.0.3.0/24. Esto generaba grandes inconsistencias de red que no tenían una causa identificada claramente. Luego de un extenso análisis de la situación se logró determinar que la red creada internamente por Openstack para la comunicación entre contenedores LXC utiliza dicho rango. En función de esta observación es que se especificó el rango 10.0.10.0/24 para la red vxlan.
+
+\chapter{Trabajo a futuro}
+
+\subsubsection{Firewall}
+Deshabilitar por completo la denegación de paquetes por defecto en el firewall de CentOS deja el servidor expuesto ante vulnerabilidades, lo cual para un ambiente de producción es inadmisible. Como aspecto a mejorar se propone analizar y documentar todas las conexiones HTTP realizadas por Openstack Ansible durante su instalación y en su posterior ejecución entre cada uno de los nodos involucrados. Una vez identificadas, se debe agregar en cada nodo las reglas iptables correspondientes que habiliten dichas conexiones en particular.
+
+\subsubsection{Arquitectura segura}
+Se propone evaluar diversos diseños de arquitectura que involucren la utilización de un firewall que separe adecuadamente la red interna de la pública utilizando opcionalmente una DMZ. Esta evaluación debe tener en cuenta tanto accesos SSH a los nodos del datacenter por parte de administradores, como accesos directos a las instancias utilizadas por los usuarios finales. Además, debe permitir el tráfico HTTP para la correcta interacción con el dashboard de la plataforma.\\
+A la hora de tomar una decisión se debe considerar que de momento no se cuenta con una conexión directa hacia el exterior, por lo que en caso de que esto ocurra se debe reforzar adecuadamente la seguridad del datacenter.
+
+\subsubsection{Brindar conexión directa a Internet}
+Con el fin de simplificar el acceso hacia el exterior tanto durante la instalación como en su posterior ejecución, se debe evaluar una solución que permita mantener una conexión directa con el proxy de la FIng, evitando así la necesidad de realizar un túnel SSH como fue mencionado en la descripción del ambiente de trabajo.
+
+\subsubsection{Gestión de Openstack en operación}
+Es sumamente relevante investigar la gestión en caliente de un datacenter implementado mediante Openstack. Esto involucra tener un manual con pasos claros a realizar en circunstancias tales como escalar horizontalmente el datacenter, reemplazar nodos core y recuperar el funcionamiento ante eventos externos.
+
+
+\chapter{Conclusiones}
+Luego de haber realizado todo el proceso de despliegue de un datacenter de pruebas mediante Openstack, se tomó conciencia de todos los aspectos y conceptos que involucra la instalación y mantenimiento de una operativa de esta magnitud. Es por esto que para llevar a cabo el trabajo fue necesario adquirir y aplicar conocimientos en diversas áreas computacionales tales como virtualización y contenerización, gestión de redes, almacenamiento de datos y administración de sistemas.\\
+
+Openstack como herramienta resulta ser muy valorada gracias a que posee una gran flexibilidad para adecuar el despliegue de un datacenter a las necesidades de cada caso, permitiendo instalar módulos con funcionalidades específicas y prescindir de aquellos que no sean necesarios. \\
+
+El proceso de instalación resulta sumamente complejo debido a la cantidad de herramientas y configuraciones a tener en cuenta, es por eso que la utilización de una herramienta de automatización de tareas resulta inevitable. Como se menciona en el documento, se utilizó Ansible para facilitar el proceso ya que permite ejecutar instalaciones reiteradas veces de forma idéntica y sobre múltiples servidores sin una carga operativa adicional. Aún así, la experiencia no fue sencilla debido a los diversos inconvenientes que se encontraron durante el camino. Esto condujo a que lograr todo el trabajo llevará un tiempo mayor al estimado.\\
+
+Finalmente se resalta el gran apoyo e inversión a nivel internacional en esta plataforma, y los niveles de crecimiento que tuvo y continúa teniendo en esta década, indicando que es algo por lo que apostar a futuro.
+
+
+% BIBLIOGRAFIA CON BIBTEX
+\clearpage \newpage
+\nocite{*}
+\bibliographystyle{plain}
+\bibliography{references}
+\end{document}
diff --git a/taller/docs/latex/report.toc b/taller/docs/latex/report.toc
new file mode 100644
index 0000000000000000000000000000000000000000..384511f9b05c5d00d66c3801cfa1e8e378787dfc
--- /dev/null
+++ b/taller/docs/latex/report.toc
@@ -0,0 +1,121 @@
+\babel@toc {spanish}{}
+\contentsline {chapter}{\numberline {1}Introducci\IeC {\'o}n}{3}{chapter.1}
+\contentsline {chapter}{\numberline {2}Marco te\IeC {\'o}rico}{4}{chapter.2}
+\contentsline {section}{\numberline {2.1}Cloud computing}{4}{section.2.1}
+\contentsline {section}{\numberline {2.2}Virtualizaci\IeC {\'o}n}{5}{section.2.2}
+\contentsline {subparagraph}{KVM}{5}{section*.3}
+\contentsline {section}{\numberline {2.3}Contenerizaci\IeC {\'o}n}{6}{section.2.3}
+\contentsline {subparagraph}{LXC}{6}{section*.5}
+\contentsline {section}{\numberline {2.4}Datacenters}{6}{section.2.4}
+\contentsline {section}{\numberline {2.5}Redes}{7}{section.2.5}
+\contentsline {subparagraph}{Flat}{7}{section*.6}
+\contentsline {subparagraph}{VLAN}{7}{section*.7}
+\contentsline {subparagraph}{VXLAN}{8}{section*.8}
+\contentsline {chapter}{\numberline {3}Openstack}{9}{chapter.3}
+\contentsline {section}{\numberline {3.1}Origen y definici\IeC {\'o}n}{9}{section.3.1}
+\contentsline {section}{\numberline {3.2}M\IeC {\'o}dulos Core}{9}{section.3.2}
+\contentsline {subsection}{\numberline {3.2.1}Keystone}{10}{subsection.3.2.1}
+\contentsline {subsection}{\numberline {3.2.2}Nova}{11}{subsection.3.2.2}
+\contentsline {subparagraph}{API}{12}{section*.12}
+\contentsline {subparagraph}{Scheduler}{12}{section*.13}
+\contentsline {subparagraph}{Compute}{12}{section*.14}
+\contentsline {subparagraph}{Conductor}{13}{section*.15}
+\contentsline {subparagraph}{Placement}{13}{section*.16}
+\contentsline {subsection}{\numberline {3.2.3}Neutron}{13}{subsection.3.2.3}
+\contentsline {subparagraph}{Neutron-server}{14}{section*.18}
+\contentsline {subparagraph}{Plugins y agentes}{14}{section*.19}
+\contentsline {subparagraph}{Cola de mensajes}{14}{section*.20}
+\contentsline {subsubsection}{Tipos de redes en Openstack}{14}{section*.21}
+\contentsline {subsubsection}{Tipo de tr\IeC {\'a}fico}{15}{section*.22}
+\contentsline {subsection}{\numberline {3.2.4}Glance}{15}{subsection.3.2.4}
+\contentsline {subparagraph}{Creaci\IeC {\'o}n de una VM}{16}{section*.24}
+\contentsline {subsection}{\numberline {3.2.5}Cinder}{17}{subsection.3.2.5}
+\contentsline {subsection}{\numberline {3.2.6}Swift}{19}{subsection.3.2.6}
+\contentsline {subparagraph}{Principales componentes}{19}{section*.28}
+\contentsline {section}{\numberline {3.3}Tipos de nodos}{20}{section.3.3}
+\contentsline {subparagraph}{Nodo de control}{20}{section*.29}
+\contentsline {subparagraph}{Nodo de red}{20}{section*.30}
+\contentsline {subparagraph}{Nodo de c\IeC {\'o}mputo}{21}{section*.32}
+\contentsline {subparagraph}{Nodo de almacenamiento}{21}{section*.33}
+\contentsline {subparagraph}{Nodo de balanceamiento de carga}{21}{section*.34}
+\contentsline {section}{\numberline {3.4}Servicios de infraestructura}{21}{section.3.4}
+\contentsline {subparagraph}{Galera - MariaDB}{21}{section*.35}
+\contentsline {subparagraph}{Message queue}{22}{section*.36}
+\contentsline {subparagraph}{Memcached}{22}{section*.37}
+\contentsline {section}{\numberline {3.5}M\IeC {\'e}todos de instalaci\IeC {\'o}n}{22}{section.3.5}
+\contentsline {subsection}{\numberline {3.5.1}Ansible}{23}{subsection.3.5.1}
+\contentsline {subparagraph}{Nodo de control}{23}{section*.38}
+\contentsline {subparagraph}{Inventario}{23}{section*.39}
+\contentsline {subparagraph}{M\IeC {\'o}dulos}{23}{section*.40}
+\contentsline {subparagraph}{Tarea}{23}{section*.41}
+\contentsline {subparagraph}{Playbook}{23}{section*.42}
+\contentsline {section}{\numberline {3.6}Arquitectura}{23}{section.3.6}
+\contentsline {subsection}{\numberline {3.6.1}Arquitectura de red}{24}{subsection.3.6.1}
+\contentsline {subparagraph}{Management Network}{24}{section*.44}
+\contentsline {subparagraph}{Overlay Network}{24}{section*.45}
+\contentsline {subparagraph}{Storage Network}{24}{section*.46}
+\contentsline {subsubsection}{Interfaces de red}{24}{section*.47}
+\contentsline {section}{\numberline {3.7}Configuraci\IeC {\'o}n OSA}{28}{section.3.7}
+\contentsline {subsection}{\numberline {3.7.1}Convenciones}{28}{subsection.3.7.1}
+\contentsline {subsection}{\numberline {3.7.2}Inventario}{29}{subsection.3.7.2}
+\contentsline {subsection}{\numberline {3.7.3}openstack\_user\_config.yml}{29}{subsection.3.7.3}
+\contentsline {chapter}{\numberline {4}Instalaci\IeC {\'o}n}{30}{chapter.4}
+\contentsline {section}{\numberline {4.1}Dise\IeC {\~n}o de arquitectura}{30}{section.4.1}
+\contentsline {section}{\numberline {4.2}Ambiente de trabajo}{32}{section.4.2}
+\contentsline {subsection}{\numberline {4.2.1}Hardware utilizado}{32}{subsection.4.2.1}
+\contentsline {subsection}{\numberline {4.2.2}Conexi\IeC {\'o}n remota hacia el servidor renata}{33}{subsection.4.2.2}
+\contentsline {subsection}{\numberline {4.2.3}Virtualizaci\IeC {\'o}n con KVM}{33}{subsection.4.2.3}
+\contentsline {subsubsection}{Utilizaci\IeC {\'o}n virt-manager}{34}{section*.55}
+\contentsline {subsection}{\numberline {4.2.4}Especificaciones servidor renata}{40}{subsection.4.2.4}
+\contentsline {subsection}{\numberline {4.2.5}Acceso al exterior desde nodos}{41}{subsection.4.2.5}
+\contentsline {section}{\numberline {4.3}Preparaci\IeC {\'o}n de nodos}{42}{section.4.3}
+\contentsline {subsubsection}{Deploy}{42}{section*.73}
+\contentsline {subsubsection}{Infra1}{44}{section*.75}
+\contentsline {subsubsection}{Compute1}{46}{section*.76}
+\contentsline {subsubsection}{Storage1}{46}{section*.77}
+\contentsline {subsubsection}{HAproxy1}{47}{section*.78}
+\contentsline {section}{\numberline {4.4}Configuraci\IeC {\'o}n}{48}{section.4.4}
+\contentsline {subsection}{\numberline {4.4.1}Configuraci\IeC {\'o}n claves SSH}{48}{subsection.4.4.1}
+\contentsline {subsection}{\numberline {4.4.2}Archivos de configuraci\IeC {\'o}n OSA}{49}{subsection.4.4.2}
+\contentsline {subsubsection}{openstack\_user\_config.yml}{49}{section*.79}
+\contentsline {subsubsection}{user\_variables.yml}{51}{section*.80}
+\contentsline {subsubsection}{cinder.yml}{52}{section*.81}
+\contentsline {subsection}{\numberline {4.4.3}Generaci\IeC {\'o}n de claves}{52}{subsection.4.4.3}
+\contentsline {subsection}{\numberline {4.4.4}Correcciones}{52}{subsection.4.4.4}
+\contentsline {subsubsection}{SELinux}{52}{section*.82}
+\contentsline {section}{\numberline {4.5}Ejecuci\IeC {\'o}n de playbooks}{53}{section.4.5}
+\contentsline {subsubsection}{setup-hosts.yml}{53}{section*.83}
+\contentsline {subsubsection}{install-haproxy.yml}{53}{section*.84}
+\contentsline {subsubsection}{setup-infrastructure.yml}{53}{section*.85}
+\contentsline {subsubsection}{setup-openstack.yml}{54}{section*.86}
+\contentsline {section}{\numberline {4.6}Verificaci\IeC {\'o}n}{54}{section.4.6}
+\contentsline {chapter}{\numberline {5}Interaccci\IeC {\'o}n}{55}{chapter.5}
+\contentsline {section}{\numberline {5.1}Configuraciones de administrador}{56}{section.5.1}
+\contentsline {subsubsection}{Crear proyecto}{56}{section*.88}
+\contentsline {subsubsection}{Crear usuario}{57}{section*.91}
+\contentsline {subsubsection}{Crear flavor}{58}{section*.93}
+\contentsline {subsubsection}{Crear provider network}{60}{section*.96}
+\contentsline {section}{\numberline {5.2}Interacci\IeC {\'o}n de un usuario}{61}{section.5.2}
+\contentsline {subsubsection}{Crear imagen}{61}{section*.99}
+\contentsline {subsubsection}{Crear red}{63}{section*.102}
+\contentsline {subsubsection}{Crear router}{65}{section*.106}
+\contentsline {subsubsection}{Crear interfaz de router}{65}{section*.108}
+\contentsline {subsubsection}{Crear key pair}{66}{section*.110}
+\contentsline {subsubsection}{Lanzar una instancia}{66}{section*.112}
+\contentsline {section}{\numberline {5.3}Acceso a una instancia}{69}{section.5.3}
+\contentsline {subsection}{\numberline {5.3.1}Por SPICE}{69}{subsection.5.3.1}
+\contentsline {subsection}{\numberline {5.3.2}Por SSH}{70}{subsection.5.3.2}
+\contentsline {subsubsection}{Asociar una Floating IP a la instancia}{70}{section*.118}
+\contentsline {subsubsection}{Modificar security group}{70}{section*.121}
+\contentsline {subsubsection}{SSH}{72}{section*.125}
+\contentsline {chapter}{\numberline {6}Inconvenientes}{73}{chapter.6}
+\contentsline {subsubsection}{Bloqueo de paquetes}{73}{section*.126}
+\contentsline {subsubsection}{M\IeC {\'o}dulo de seguridad SELinux}{73}{section*.127}
+\contentsline {subsubsection}{Percona-release en playbook setup-infrastructure}{73}{section*.128}
+\contentsline {subsubsection}{Subred reservada}{74}{section*.129}
+\contentsline {chapter}{\numberline {7}Trabajo a futuro}{75}{chapter.7}
+\contentsline {subsubsection}{Firewall}{75}{section*.130}
+\contentsline {subsubsection}{Arquitectura segura}{75}{section*.131}
+\contentsline {subsubsection}{Brindar conexi\IeC {\'o}n directa a Internet}{75}{section*.132}
+\contentsline {subsubsection}{Gesti\IeC {\'o}n de Openstack en operaci\IeC {\'o}n}{75}{section*.133}
+\contentsline {chapter}{\numberline {8}Conclusiones}{76}{chapter.8}
diff --git a/taller/docs/latex/resources/acceso-renata.jpg b/taller/docs/latex/resources/acceso-renata.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..7cc979dc4275cd0e995e9da03d26a6609a8e6598
Binary files /dev/null and b/taller/docs/latex/resources/acceso-renata.jpg differ
diff --git a/taller/docs/latex/resources/bonded-interfaces.png b/taller/docs/latex/resources/bonded-interfaces.png
new file mode 100644
index 0000000000000000000000000000000000000000..ece72874bcbb4d6d01e14982cf9b57605383b423
Binary files /dev/null and b/taller/docs/latex/resources/bonded-interfaces.png differ
diff --git a/taller/docs/latex/resources/cinder.png b/taller/docs/latex/resources/cinder.png
new file mode 100644
index 0000000000000000000000000000000000000000..545a6d85448199002f0af0e063bd70beb5ed6263
Binary files /dev/null and b/taller/docs/latex/resources/cinder.png differ
diff --git a/taller/docs/latex/resources/containers-deploy.png b/taller/docs/latex/resources/containers-deploy.png
new file mode 100644
index 0000000000000000000000000000000000000000..8ef5a74ff3bc9713c8aa0a997a08452c3d2d3ac1
Binary files /dev/null and b/taller/docs/latex/resources/containers-deploy.png differ
diff --git a/taller/docs/latex/resources/containers.png b/taller/docs/latex/resources/containers.png
new file mode 100644
index 0000000000000000000000000000000000000000..9bf638b47fe76d683f272b0d26a2a5438d149ec5
Binary files /dev/null and b/taller/docs/latex/resources/containers.png differ
diff --git a/taller/docs/latex/resources/diagrama-openstack-1.jpg b/taller/docs/latex/resources/diagrama-openstack-1.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..38b3800426b8dadfa379e4a4973c1c1537122d59
Binary files /dev/null and b/taller/docs/latex/resources/diagrama-openstack-1.jpg differ
diff --git a/taller/docs/latex/resources/dis-arquitectura.jpg b/taller/docs/latex/resources/dis-arquitectura.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..7599cfdce4a3c74b46a00d11ebf5db123f198649
Binary files /dev/null and b/taller/docs/latex/resources/dis-arquitectura.jpg differ
diff --git a/taller/docs/latex/resources/fing.jpg b/taller/docs/latex/resources/fing.jpg
new file mode 100644
index 0000000000000000000000000000000000000000..f7609a93570cde9e5a188b48646ec81153949ac7
Binary files /dev/null and b/taller/docs/latex/resources/fing.jpg differ
diff --git a/taller/docs/latex/resources/glance.png b/taller/docs/latex/resources/glance.png
new file mode 100644
index 0000000000000000000000000000000000000000..e02f13b9a9d406a2973bcc0b659bac413c58b219
Binary files /dev/null and b/taller/docs/latex/resources/glance.png differ
diff --git a/taller/docs/latex/resources/glance2.png b/taller/docs/latex/resources/glance2.png
new file mode 100644
index 0000000000000000000000000000000000000000..29883065621c332252eb2795bbac4f3f3c22bf1f
Binary files /dev/null and b/taller/docs/latex/resources/glance2.png differ
diff --git a/taller/docs/latex/resources/hypervisors.png b/taller/docs/latex/resources/hypervisors.png
new file mode 100644
index 0000000000000000000000000000000000000000..db5a0a51918f41f4bf2921d09f0c770fec893c35
Binary files /dev/null and b/taller/docs/latex/resources/hypervisors.png differ
diff --git a/taller/docs/latex/resources/interfaces.png b/taller/docs/latex/resources/interfaces.png
new file mode 100644
index 0000000000000000000000000000000000000000..c59607870e2a22cdee6159dc2b1ad19ab80b5b02
Binary files /dev/null and b/taller/docs/latex/resources/interfaces.png differ
diff --git a/taller/docs/latex/resources/internet-nodos.png b/taller/docs/latex/resources/internet-nodos.png
new file mode 100644
index 0000000000000000000000000000000000000000..b8a49d59bd053ea62ef8f8227ca207ccbf79b1bb
Binary files /dev/null and b/taller/docs/latex/resources/internet-nodos.png differ
diff --git a/taller/docs/latex/resources/keystone.png b/taller/docs/latex/resources/keystone.png
new file mode 100644
index 0000000000000000000000000000000000000000..f593799f9c05fbe360cc8577277ca08e0526bf30
Binary files /dev/null and b/taller/docs/latex/resources/keystone.png differ
diff --git a/taller/docs/latex/resources/network-components.png b/taller/docs/latex/resources/network-components.png
new file mode 100644
index 0000000000000000000000000000000000000000..e389b36e606ad615e06b9847b6cc26d43c79be33
Binary files /dev/null and b/taller/docs/latex/resources/network-components.png differ
diff --git a/taller/docs/latex/resources/neutron.png b/taller/docs/latex/resources/neutron.png
new file mode 100644
index 0000000000000000000000000000000000000000..1d059c5ed70db0e0e114f20600eb292a489fa419
Binary files /dev/null and b/taller/docs/latex/resources/neutron.png differ
diff --git a/taller/docs/latex/resources/neutron2.png b/taller/docs/latex/resources/neutron2.png
new file mode 100644
index 0000000000000000000000000000000000000000..e234019ac2e032e5f03c915f0263f0155672e3a6
Binary files /dev/null and b/taller/docs/latex/resources/neutron2.png differ
diff --git a/taller/docs/latex/resources/neutron3.png b/taller/docs/latex/resources/neutron3.png
new file mode 100644
index 0000000000000000000000000000000000000000..621c09648335e6d13d5500fac5d5f57371675495
Binary files /dev/null and b/taller/docs/latex/resources/neutron3.png differ
diff --git a/taller/docs/latex/resources/nova.png b/taller/docs/latex/resources/nova.png
new file mode 100644
index 0000000000000000000000000000000000000000..3eab8843cd43a57969a59b868f78f28a144dacd0
Binary files /dev/null and b/taller/docs/latex/resources/nova.png differ
diff --git a/taller/docs/latex/resources/openstack-add-interface.png b/taller/docs/latex/resources/openstack-add-interface.png
new file mode 100644
index 0000000000000000000000000000000000000000..dd9bf2a4ff0d224f27819b86c039adc215acdd71
Binary files /dev/null and b/taller/docs/latex/resources/openstack-add-interface.png differ
diff --git a/taller/docs/latex/resources/openstack-allocate-floating-ip.png b/taller/docs/latex/resources/openstack-allocate-floating-ip.png
new file mode 100644
index 0000000000000000000000000000000000000000..4aa3425b99f23753e6a2fc9144ec9c907978a91a
Binary files /dev/null and b/taller/docs/latex/resources/openstack-allocate-floating-ip.png differ
diff --git a/taller/docs/latex/resources/openstack-associate-floating-ip.png b/taller/docs/latex/resources/openstack-associate-floating-ip.png
new file mode 100644
index 0000000000000000000000000000000000000000..5dc80dd0f7aab5848587582e03b577109581518c
Binary files /dev/null and b/taller/docs/latex/resources/openstack-associate-floating-ip.png differ
diff --git a/taller/docs/latex/resources/openstack-create-flavor-2.png b/taller/docs/latex/resources/openstack-create-flavor-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..c603896417cf9ff34176fbd734627d2a343a9bd7
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-flavor-2.png differ
diff --git a/taller/docs/latex/resources/openstack-create-flavor.png b/taller/docs/latex/resources/openstack-create-flavor.png
new file mode 100644
index 0000000000000000000000000000000000000000..acce13f06843543b03c1a7c20eb605c34b282d46
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-flavor.png differ
diff --git a/taller/docs/latex/resources/openstack-create-image-1.png b/taller/docs/latex/resources/openstack-create-image-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..650209c9e46cbfd67202c21b9b857e30cfe56bc4
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-image-1.png differ
diff --git a/taller/docs/latex/resources/openstack-create-image-2.png b/taller/docs/latex/resources/openstack-create-image-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..668616d4f9cb12210b175dde00ece346f3885af0
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-image-2.png differ
diff --git a/taller/docs/latex/resources/openstack-create-key-pair.png b/taller/docs/latex/resources/openstack-create-key-pair.png
new file mode 100644
index 0000000000000000000000000000000000000000..7713437d085c9c694c1110ffec22ed485aa3c6a6
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-key-pair.png differ
diff --git a/taller/docs/latex/resources/openstack-create-network-1.png b/taller/docs/latex/resources/openstack-create-network-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..09c8f53e2e248340fd03cd286497a0af35367a30
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-network-1.png differ
diff --git a/taller/docs/latex/resources/openstack-create-network-2.png b/taller/docs/latex/resources/openstack-create-network-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..a8cbb00d31289d626abdf425a1efa69cbea89498
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-network-2.png differ
diff --git a/taller/docs/latex/resources/openstack-create-network-3.png b/taller/docs/latex/resources/openstack-create-network-3.png
new file mode 100644
index 0000000000000000000000000000000000000000..22ce74b43d1d6050b928078512ab22f09ad7eb23
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-network-3.png differ
diff --git a/taller/docs/latex/resources/openstack-create-project-2.png b/taller/docs/latex/resources/openstack-create-project-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..e7219d0f0b19e98b595901cfed7944d9537726e1
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-project-2.png differ
diff --git a/taller/docs/latex/resources/openstack-create-project.png b/taller/docs/latex/resources/openstack-create-project.png
new file mode 100644
index 0000000000000000000000000000000000000000..3018c8ec8e8d0d5e0b7e3dd1d5548ed40d219fc4
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-project.png differ
diff --git a/taller/docs/latex/resources/openstack-create-provider-network-1.png b/taller/docs/latex/resources/openstack-create-provider-network-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..f8657d3dc3d62b81b1f9f066d52628c28dcd586b
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-provider-network-1.png differ
diff --git a/taller/docs/latex/resources/openstack-create-provider-network-2.png b/taller/docs/latex/resources/openstack-create-provider-network-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..6adbbc590e0bf8a8754e942a5c665302c8d98693
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-provider-network-2.png differ
diff --git a/taller/docs/latex/resources/openstack-create-router-interface.png b/taller/docs/latex/resources/openstack-create-router-interface.png
new file mode 100644
index 0000000000000000000000000000000000000000..50cd3104ae4869e54f37db04065ce08b7ba8904f
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-router-interface.png differ
diff --git a/taller/docs/latex/resources/openstack-create-router.png b/taller/docs/latex/resources/openstack-create-router.png
new file mode 100644
index 0000000000000000000000000000000000000000..40eeacb21af920c7b21dcd51e254ff4ef201fcd2
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-router.png differ
diff --git a/taller/docs/latex/resources/openstack-create-security-rule-icmp.png b/taller/docs/latex/resources/openstack-create-security-rule-icmp.png
new file mode 100644
index 0000000000000000000000000000000000000000..3ec7b660dab3af7ba7b54453a5a6c48bce206e84
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-security-rule-icmp.png differ
diff --git a/taller/docs/latex/resources/openstack-create-security-rule-ssh.png b/taller/docs/latex/resources/openstack-create-security-rule-ssh.png
new file mode 100644
index 0000000000000000000000000000000000000000..b517cfb3fadf629c95dc23b07c2580d9615f4e4a
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-security-rule-ssh.png differ
diff --git a/taller/docs/latex/resources/openstack-create-user.png b/taller/docs/latex/resources/openstack-create-user.png
new file mode 100644
index 0000000000000000000000000000000000000000..ed4795f64856735b77cb01d876cbbc7f0e1ffa8a
Binary files /dev/null and b/taller/docs/latex/resources/openstack-create-user.png differ
diff --git a/taller/docs/latex/resources/openstack-launch-instance-1.png b/taller/docs/latex/resources/openstack-launch-instance-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..a1145a6dcbf32787c968d7602093e81df6a9ab19
Binary files /dev/null and b/taller/docs/latex/resources/openstack-launch-instance-1.png differ
diff --git a/taller/docs/latex/resources/openstack-launch-instance-2.png b/taller/docs/latex/resources/openstack-launch-instance-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..553d967177a1b2c2c0db0e1897664f337ffafb87
Binary files /dev/null and b/taller/docs/latex/resources/openstack-launch-instance-2.png differ
diff --git a/taller/docs/latex/resources/openstack-launch-instance-3.png b/taller/docs/latex/resources/openstack-launch-instance-3.png
new file mode 100644
index 0000000000000000000000000000000000000000..5e59477c71404e3d9853faed17548ed2e0294baa
Binary files /dev/null and b/taller/docs/latex/resources/openstack-launch-instance-3.png differ
diff --git a/taller/docs/latex/resources/openstack-launch-instance-4.png b/taller/docs/latex/resources/openstack-launch-instance-4.png
new file mode 100644
index 0000000000000000000000000000000000000000..f145e5c3e55faa0648024798304eb7cd5d5cbc12
Binary files /dev/null and b/taller/docs/latex/resources/openstack-launch-instance-4.png differ
diff --git a/taller/docs/latex/resources/openstack-launch-instance-5.png b/taller/docs/latex/resources/openstack-launch-instance-5.png
new file mode 100644
index 0000000000000000000000000000000000000000..56be40b8f6502097d1288555b0ee31bb1cffc30f
Binary files /dev/null and b/taller/docs/latex/resources/openstack-launch-instance-5.png differ
diff --git a/taller/docs/latex/resources/openstack-login.png b/taller/docs/latex/resources/openstack-login.png
new file mode 100644
index 0000000000000000000000000000000000000000..5fc780592119255d85e2b0923ab8948423ff6edf
Binary files /dev/null and b/taller/docs/latex/resources/openstack-login.png differ
diff --git a/taller/docs/latex/resources/openstack-modules.png b/taller/docs/latex/resources/openstack-modules.png
new file mode 100644
index 0000000000000000000000000000000000000000..2802e7b6817568b4049228b8d639a1fd07fa007d
Binary files /dev/null and b/taller/docs/latex/resources/openstack-modules.png differ
diff --git a/taller/docs/latex/resources/openstack-security-group-default.png b/taller/docs/latex/resources/openstack-security-group-default.png
new file mode 100644
index 0000000000000000000000000000000000000000..77aa6b5424ede511ca42d26a82c058f0605b18b1
Binary files /dev/null and b/taller/docs/latex/resources/openstack-security-group-default.png differ
diff --git a/taller/docs/latex/resources/redes-renata.png b/taller/docs/latex/resources/redes-renata.png
new file mode 100644
index 0000000000000000000000000000000000000000..2bb043f94fa93415f4b6cc5276cc043e3e0e1739
Binary files /dev/null and b/taller/docs/latex/resources/redes-renata.png differ
diff --git a/taller/docs/latex/resources/swift.png b/taller/docs/latex/resources/swift.png
new file mode 100644
index 0000000000000000000000000000000000000000..5147a6034f851ea546e6b194a730c59db3bfdd85
Binary files /dev/null and b/taller/docs/latex/resources/swift.png differ
diff --git a/taller/docs/latex/resources/virt-conf-red.png b/taller/docs/latex/resources/virt-conf-red.png
new file mode 100644
index 0000000000000000000000000000000000000000..ce0dde81e06eda5704d9e7abff112be62db1316a
Binary files /dev/null and b/taller/docs/latex/resources/virt-conf-red.png differ
diff --git a/taller/docs/latex/resources/virt-manager-eth0.png b/taller/docs/latex/resources/virt-manager-eth0.png
new file mode 100644
index 0000000000000000000000000000000000000000..db906265fb91a49f2d47002dffa3fb0bddeab484
Binary files /dev/null and b/taller/docs/latex/resources/virt-manager-eth0.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-1.png b/taller/docs/latex/resources/virt-nodo-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..0a8e95009564402c4fd6cf3b3ba2e4e40bec0414
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-1.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-2.png b/taller/docs/latex/resources/virt-nodo-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..ef304b002a4bfcc7248266829c41cf2d3c56e019
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-2.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-3.png b/taller/docs/latex/resources/virt-nodo-3.png
new file mode 100644
index 0000000000000000000000000000000000000000..c02f5a1a0fb49752de415e071316f0df9affa939
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-3.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-4a.png b/taller/docs/latex/resources/virt-nodo-4a.png
new file mode 100644
index 0000000000000000000000000000000000000000..bfeba6d8f9aeb2071664d6f2d54f6d0537c7e724
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-4a.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-4b.png b/taller/docs/latex/resources/virt-nodo-4b.png
new file mode 100644
index 0000000000000000000000000000000000000000..f0bffbb5a47801b3577373f123c5ee3b322d9704
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-4b.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-4c.png b/taller/docs/latex/resources/virt-nodo-4c.png
new file mode 100644
index 0000000000000000000000000000000000000000..111dd23d7b3bf2d649efa7102ddd632574b8ca70
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-4c.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-5.png b/taller/docs/latex/resources/virt-nodo-5.png
new file mode 100644
index 0000000000000000000000000000000000000000..d9feee178b76c615fe0732fcce4e7741bafc8e86
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-5.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-6.png b/taller/docs/latex/resources/virt-nodo-6.png
new file mode 100644
index 0000000000000000000000000000000000000000..0270e5f1bb8bcccb436572892a0af0f05bd499e8
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-6.png differ
diff --git a/taller/docs/latex/resources/virt-nodo-7.png b/taller/docs/latex/resources/virt-nodo-7.png
new file mode 100644
index 0000000000000000000000000000000000000000..116c878456f69ec912868f45cd36b5ffaac07bd6
Binary files /dev/null and b/taller/docs/latex/resources/virt-nodo-7.png differ
diff --git a/taller/docs/latex/resources/virt-nueva-conexion.png b/taller/docs/latex/resources/virt-nueva-conexion.png
new file mode 100644
index 0000000000000000000000000000000000000000..77f8c62027a0e04a19a1a5c04ac93f6de940f02c
Binary files /dev/null and b/taller/docs/latex/resources/virt-nueva-conexion.png differ
diff --git a/taller/docs/latex/resources/virt-red-1.png b/taller/docs/latex/resources/virt-red-1.png
new file mode 100644
index 0000000000000000000000000000000000000000..3c90fb6b8b898f7659a0213fa1d11f3dc6f16cdb
Binary files /dev/null and b/taller/docs/latex/resources/virt-red-1.png differ
diff --git a/taller/docs/latex/resources/virt-red-2.png b/taller/docs/latex/resources/virt-red-2.png
new file mode 100644
index 0000000000000000000000000000000000000000..17fca2e888482575f60d358e3e8ee6ead4ebab9a
Binary files /dev/null and b/taller/docs/latex/resources/virt-red-2.png differ
diff --git a/taller/docs/latex/resources/virt-red-3.png b/taller/docs/latex/resources/virt-red-3.png
new file mode 100644
index 0000000000000000000000000000000000000000..457e5e92c95a5fa810e7e7d9c277480fc140901b
Binary files /dev/null and b/taller/docs/latex/resources/virt-red-3.png differ
diff --git a/taller/docs/latex/resources/virt-red-4.png b/taller/docs/latex/resources/virt-red-4.png
new file mode 100644
index 0000000000000000000000000000000000000000..5d194602aaf4a62401d27f9d9b90447bb2e5c4f9
Binary files /dev/null and b/taller/docs/latex/resources/virt-red-4.png differ
diff --git a/taller/src/compute1/network-scripts/ifcfg-br-mgmt b/taller/src/compute1/network-scripts/ifcfg-br-mgmt
new file mode 100644
index 0000000000000000000000000000000000000000..c5ce47d616cdfc6ae41283f81cb0a873cf2958f2
--- /dev/null
+++ b/taller/src/compute1/network-scripts/ifcfg-br-mgmt
@@ -0,0 +1,9 @@
+DEVICE=br-mgmt
+BOOTPROTO=none
+IPADDR=10.0.1.12
+PREFIX=24
+GATEWAY=10.0.1.1
+DNS1=192.168.60.230
+ONBOOT=yes
+TYPE=Bridge
+NM_CONTROLLED=no
diff --git a/taller/src/compute1/network-scripts/ifcfg-br-storage b/taller/src/compute1/network-scripts/ifcfg-br-storage
new file mode 100644
index 0000000000000000000000000000000000000000..552b709528badbadc3ba064c002b04c57e122c0b
--- /dev/null
+++ b/taller/src/compute1/network-scripts/ifcfg-br-storage
@@ -0,0 +1,7 @@
+DEVICE=br-storage
+BOOTPROTO=none
+IPADDR=10.0.2.12
+PREFIX=24
+ONBOOT=yes
+TYPE=Bridge
+NM_CONTROLLED=no
diff --git a/taller/src/compute1/network-scripts/ifcfg-br-vxlan b/taller/src/compute1/network-scripts/ifcfg-br-vxlan
new file mode 100644
index 0000000000000000000000000000000000000000..15c903baac6767773dad75c032ece0baf9224147
--- /dev/null
+++ b/taller/src/compute1/network-scripts/ifcfg-br-vxlan
@@ -0,0 +1,7 @@
+DEVICE=br-vxlan
+BOOTPROTO=none
+IPADDR=10.0.10.12
+PREFIX=24
+ONBOOT=yes
+TYPE=Bridge
+NM_CONTROLLED=no
diff --git a/taller/src/compute1/network-scripts/ifcfg-eth0 b/taller/src/compute1/network-scripts/ifcfg-eth0
new file mode 100644
index 0000000000000000000000000000000000000000..516f94c2284d364fb596de0763e22aa17378c2c1
--- /dev/null
+++ b/taller/src/compute1/network-scripts/ifcfg-eth0
@@ -0,0 +1,6 @@
+TYPE="Ethernet"
+BOOTPROTO=none
+DEVICE=eth0
+ONBOOT=yes
+NM_CONTROLLED=no
+BRIDGE=br-mgmt
diff --git a/taller/src/compute1/network-scripts/ifcfg-eth1 b/taller/src/compute1/network-scripts/ifcfg-eth1
new file mode 100644
index 0000000000000000000000000000000000000000..bda8690c215c11338b32901bb44c2308fb2ac66e
--- /dev/null
+++ b/taller/src/compute1/network-scripts/ifcfg-eth1
@@ -0,0 +1,6 @@
+TYPE="Ethernet"
+BOOTPROTO=none
+DEVICE=eth1
+ONBOOT=yes
+NM_CONTROLLED=no
+BRIDGE=br-storage
diff --git a/taller/src/compute1/network-scripts/ifcfg-eth2 b/taller/src/compute1/network-scripts/ifcfg-eth2
new file mode 100644
index 0000000000000000000000000000000000000000..1fcbbc9656bc6a98724320f03aee30a50116dde2
--- /dev/null
+++ b/taller/src/compute1/network-scripts/ifcfg-eth2
@@ -0,0 +1,6 @@
+TYPE="Ethernet"
+BOOTPROTO=none
+DEVICE=eth2
+ONBOOT=yes
+NM_CONTROLLED=no
+BRIDGE=br-vxlan
diff --git a/taller/src/compute1/network-scripts/ifcfg-eth3 b/taller/src/compute1/network-scripts/ifcfg-eth3
new file mode 100644
index 0000000000000000000000000000000000000000..304aba6df83d5e37db8e2a8c07a37375ff3e4925
--- /dev/null
+++ b/taller/src/compute1/network-scripts/ifcfg-eth3
@@ -0,0 +1,7 @@
+TYPE="Ethernet"
+BOOTPROTO=none
+DEVICE="eth3"
+NAME="eth3"
+ONBOOT=yes
+NM_CONTROLLED=no
+
diff --git a/taller/src/deploy/cinder-volume.yml b/taller/src/deploy/cinder-volume.yml
new file mode 100644
index 0000000000000000000000000000000000000000..d348085dfb22eacb1c1f2e8b4cdaf8c3cc944550
--- /dev/null
+++ b/taller/src/deploy/cinder-volume.yml
@@ -0,0 +1,14 @@
+---
+# This file contains an example to show how to set
+# the cinder-volume service to run in a container.
+#
+# Important note:
+# When using LVM or any iSCSI-based cinder backends, such as NetApp with
+# iSCSI protocol, the cinder-volume service *must* run on metal.
+# Reference: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1226855
+
+container_skel:
+ cinder_volumes_container:
+ properties:
+ is_metal: true
+
diff --git a/taller/src/deploy/network-scripts/ifcfg-eth0 b/taller/src/deploy/network-scripts/ifcfg-eth0
new file mode 100644
index 0000000000000000000000000000000000000000..42759ba20f20eafcc765f8b04054455be8e9f2ba
--- /dev/null
+++ b/taller/src/deploy/network-scripts/ifcfg-eth0
@@ -0,0 +1,12 @@
+TYPE=Ethernet
+BOOTPROTO=none
+DEFROUTE=yes
+IPV4_FAILURE_FATAL=no
+NAME=etho
+UUID="b27d3d09-b446-4a72-a346-4d0cd307e077"
+DEVICE=eth0
+ONBOOT=yes
+IPADDR=10.0.1.10
+PREFIX=24
+GATEWAY=10.0.1.1
+DNS1=192.168.60.230
diff --git a/taller/src/deploy/openstack_user_config_test.yml b/taller/src/deploy/openstack_user_config_test.yml
new file mode 100644
index 0000000000000000000000000000000000000000..ba1aa06262799834ac2166b79dce848b528ecfa6
--- /dev/null
+++ b/taller/src/deploy/openstack_user_config_test.yml
@@ -0,0 +1,119 @@
+cidr_networks:
+ container: 10.0.1.0/24
+ tunnel: 10.0.10.0/24
+ storage: 10.0.2.0/24
+
+used_ips:
+ - "10.0.1.1,10.0.1.20" # red de management
+ - "10.0.2.1,10.0.2.20" # red de storage
+ - "10.0.10.1,10.0.10.20" # red de vxlan
+
+
+global_overrides:
+ internal_lb_vip_address: 10.0.1.12
+ external_lb_vip_address: 10.0.1.12
+ tunnel_bridge: "br-vxlan"
+ management_bridge: "br-mgmt"
+
+ provider_networks:
+ - network:
+ group_binds:
+ - all_containers
+ - hosts
+ type: "raw"
+ container_bridge: "br-mgmt"
+ container_interface: "eth1"
+ container_type: "veth"
+ ip_from_q: "container"
+ is_container_address: true
+ is_ssh_address: true
+ - network:
+ group_binds:
+ - glance_api
+ - cinder_api
+ - cinder_volume
+ - nova_compute
+ type: "raw"
+ container_bridge: "br-storage"
+ container_type: "veth"
+ container_interface: "eth2"
+ container_mtu: "9000"
+ ip_from_q: "storage"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vxlan"
+ container_type: "veth"
+ container_interface: "eth10"
+ container_mtu: "9000"
+ ip_from_q: "tunnel"
+ type: "vxlan"
+ range: "1:1000"
+ net_name: "vxlan"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vlan"
+ container_type: "veth"
+ container_interface: "eth11"
+ type: "vlan"
+ range: "101:200,301:400"
+ net_name: "vlan"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vlan"
+ container_type: "veth"
+ container_interface: "eth12"
+ host_bind_override: "eth12"
+ type: "flat"
+ net_name: "flat"
+
+shared-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+repo-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+haproxy_hosts:
+ infra2:
+ ip: 10.0.1.12
+
+os-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+identity_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+network_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+compute_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+storage-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+storage_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+ container_vars:
+ cinder_backends:
+ lvm:
+ volume_backend_name: LVM
+ volume_driver: cinder.volume.drivers.lvm.LVMVolumeDriver
+ volume_group: cinder-volumes
+ iscsi_ip_address: "10.0.2.11"
+
+log_hosts:
+ infra1:
+ ip: 10.0.1.11
+
diff --git a/taller/src/deploy/opestack_user_config_prod.yml b/taller/src/deploy/opestack_user_config_prod.yml
new file mode 100644
index 0000000000000000000000000000000000000000..299c9fd7706dfa0ac205b1e82f48394cde14c947
--- /dev/null
+++ b/taller/src/deploy/opestack_user_config_prod.yml
@@ -0,0 +1,161 @@
+---
+cidr_networks:
+ container: 10.0.1.0/24
+ tunnel: 10.0.10.0/24
+ storage: 10.0.2.0/24
+
+used_ips:
+ - "10.0.1.1,10.0.1.20" # red de management
+ - "10.0.2.1,10.0.2.20" # red de storage
+ - "10.0.10.1,10.0.10.20" # red de vxlan
+
+
+global_overrides:
+ internal_lb_vip_address: 10.0.1.15
+ #
+ # The below domain name must resolve to an IP address
+ # in the CIDR specified in haproxy_keepalived_external_vip_cidr.
+ # If using different protocols (https/http) for the public/internal
+ # endpoints the two addresses must be different.
+ #
+ external_lb_vip_address: 192.168.60.160
+ tunnel_bridge: "br-vxlan"
+ management_bridge: "br-mgmt"
+
+ provider_networks:
+ - network:
+ group_binds:
+ - all_containers
+ - hosts
+ type: "raw"
+ container_bridge: "br-mgmt"
+ container_interface: "eth1"
+ container_type: "veth"
+ ip_from_q: "container"
+ is_container_address: true
+ is_ssh_address: true
+ - network:
+ group_binds:
+ - glance_api
+ - cinder_api
+ - cinder_volume
+ - nova_compute
+ type: "raw"
+ container_bridge: "br-storage"
+ container_type: "veth"
+ container_interface: "eth2"
+ container_mtu: "9000"
+ ip_from_q: "storage"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vxlan"
+ container_type: "veth"
+ container_interface: "eth10"
+ container_mtu: "9000"
+ ip_from_q: "tunnel"
+ type: "vxlan"
+ range: "1:1000"
+ net_name: "vxlan"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vlan"
+ container_type: "veth"
+ container_interface: "eth11"
+ host_bind_override: "eth3"
+ type: "vlan"
+ range: "101:200,301:400"
+ net_name: "vlan"
+ - network:
+ group_binds:
+ - neutron_linuxbridge_agent
+ container_bridge: "br-vlan"
+ container_type: "veth"
+ container_interface: "eth12"
+ host_bind_override: "eth3"
+ type: "flat"
+ net_name: "flat"
+
+###
+### Infrastructure
+###
+
+# galera, memcache, rabbitmq, utility
+shared-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# repository (apt cache, python packages, etc)
+repo-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# load balancer
+# Ideally the load balancer should not use the Infrastructure hosts.
+# Dedicated hardware is best for improved performance and security.
+haproxy_hosts:
+ balancer1:
+ ip: 10.0.1.15
+
+# rsyslog server
+log_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+
+###
+### OpenStack
+###
+
+# keystone
+identity_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# cinder api services
+storage-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# glance
+image_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# nova api, conductor, etc services
+compute-infra_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# heat
+orchestration_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# horizon
+dashboard_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# neutron server, agents (L3, etc)
+network_hosts:
+ infra1:
+ ip: 10.0.1.11
+
+# nova hypervisors
+compute_hosts:
+ compute1:
+ ip: 10.0.1.12
+
+# cinder volume hosts
+storage_hosts:
+ storage1:
+ ip: 10.0.1.13
+ container_vars:
+ cinder_backends:
+ lvm:
+ volume_backend_name: LVM
+ volume_driver: cinder.volume.drivers.lvm.LVMVolumeDriver
+ volume_group: cinder-volumes
+ iscsi_ip_address: "10.0.2.13"
\ No newline at end of file
diff --git a/taller/src/deploy/setupDeploy.sh b/taller/src/deploy/setupDeploy.sh
new file mode 100644
index 0000000000000000000000000000000000000000..ba124dd8167c136a518f92f58ba17a2f628b490b
--- /dev/null
+++ b/taller/src/deploy/setupDeploy.sh
@@ -0,0 +1,43 @@
+#!/bin/bash
+echo "CONFIGURANDO PROXY ..."
+sleep 1
+echo "http_proxy=http://10.0.1.1:3128" >> /etc/environment
+echo "https_proxy=http://10.0.1.1:3128" >> /etc/environment
+echo "HTTP_PROXY=http://10.0.1.1:3128" >> /etc/environment
+echo "HTTPS_PROXY=http://10.0.1.1:3128" >> /etc/environment
+for env in $( cat /etc/environment ); do export $(echo $env | sed -e 's/"//g'); done
+
+echo "ACTUALIZANDO CentOS 7..."
+yum upgrade -y
+
+echo "INSTALANDO RDO OSA QUEENS..."
+yum install -y https://rdoproject.org/repos/openstack-queens/rdo-release-queens.rpm
+
+echo "INSTALANDO HERRAMIENTAS..."
+yum install -y git ntp nano net-tools ntpdate openssh-server python-devel sudo '@Development Tools'
+
+echo "DESHABILITANDO FIREWALL"
+sleep 1
+systemctl stop firewalld
+systemctl mask firewalld
+
+echo "CONFIGURAR CHRONY MANUALMENTE!!!"
+sleep 1
+# nano /etc/chrony.conf
+# Sustituir por las líneas
+# server 0.south-america.pool.ntp.org
+# server 1.south-america.pool.ntp.org
+# server 2.south-america.pool.ntp.org
+# server 3.south-america.pool.ntp.org
+
+echo "CLANANDO REPOSITORIO GIT..."
+git clone -b 17.1.4 https://git.openstack.org/openstack/openstack-ansible /opt/openstack-ansible
+
+echo "EJECUTANDO BOOTSTRAP-ANSIBLE..."
+/opt/openstack-ansible/scripts/bootstrap-ansible.sh
+
+echo "GENERANDO CLAVES SSH..."
+ssh-keygen
+
+echo "COPIAR MANUALMENTE CLAVES SSH..."
+#ssh-copy-id root@10.0.1.11
diff --git a/taller/src/deploy/user_variables.yml b/taller/src/deploy/user_variables.yml
new file mode 100644
index 0000000000000000000000000000000000000000..b826f11dfb9510da238c4a55886fc046ad1ee7d7
--- /dev/null
+++ b/taller/src/deploy/user_variables.yml
@@ -0,0 +1,178 @@
+---
+# Copyright 2014, Rackspace US, Inc.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+###
+### This file contains commonly used overrides for convenience. Please inspect
+### the defaults for each role to find additional override options.
+###
+
+## Debug and Verbose options.
+debug: false
+
+## Common Glance Overrides
+# Set glance_default_store to "swift" if using Cloud Files backend
+# or "rbd" if using ceph backend; the latter will trigger ceph to get
+# installed on glance. If using a file store, a shared file store is
+# recommended. See the OpenStack-Ansible install guide and the OpenStack
+# documentation for more details.
+# Note that "swift" is automatically set as the default back-end if there
+# are any swift hosts in the environment. Use this setting to override
+# this automation if you wish for a different default back-end.
+# glance_default_store: file
+
+## Ceph pool name for Glance to use
+# glance_rbd_store_pool: images
+# glance_rbd_store_chunk_size: 8
+
+## Common Nova Overrides
+# When nova_libvirt_images_rbd_pool is defined, ceph will be installed on nova
+# hosts.
+# nova_libvirt_images_rbd_pool: vms
+
+# If you wish to change the dhcp_domain configured for both nova and neutron
+# dhcp_domain: openstacklocal
+
+## Common Glance Overrides when using a Swift back-end
+# By default when 'glance_default_store' is set to 'swift' the playbooks will
+# expect to use the Swift back-end that is configured in the same inventory.
+# If the Swift back-end is not in the same inventory (ie it is already setup
+# through some other means) then these settings should be used.
+#
+# NOTE: Ensure that the auth version matches your authentication endpoint.
+#
+# NOTE: If the password for glance_swift_store_key contains a dollar sign ($),
+# it must be escaped with an additional dollar sign ($$), not a backslash. For
+# example, a password of "super$ecure" would need to be entered as
+# "super$$ecure" below. See Launchpad Bug #1259729 for more details.
+#
+# glance_swift_store_auth_version: 3
+# glance_swift_store_auth_address: "https://some.auth.url.com"
+# glance_swift_store_user: "OPENSTACK_TENANT_ID:OPENSTACK_USER_NAME"
+# glance_swift_store_key: "OPENSTACK_USER_PASSWORD"
+# glance_swift_store_container: "NAME_OF_SWIFT_CONTAINER"
+# glance_swift_store_region: "NAME_OF_REGION"
+
+## Common Ceph Overrides
+# ceph_mons:
+# - 10.16.5.40
+# - 10.16.5.41
+# - 10.16.5.42
+
+## Custom Ceph Configuration File (ceph.conf)
+# By default, your deployment host will connect to one of the mons defined above to
+# obtain a copy of your cluster's ceph.conf. If you prefer, uncomment ceph_conf_file
+# and customise to avoid ceph.conf being copied from a mon.
+# ceph_conf_file: |
+# [global]
+# fsid = 00000000-1111-2222-3333-444444444444
+# mon_initial_members = mon1.example.local,mon2.example.local,mon3.example.local
+# mon_host = 10.16.5.40,10.16.5.41,10.16.5.42
+# # optionally, you can use this construct to avoid defining this list twice:
+# # mon_host = {{ ceph_mons|join(',') }}
+# auth_cluster_required = cephx
+# auth_service_required = cephx
+
+
+# By default, openstack-ansible configures all OpenStack services to talk to
+# RabbitMQ over encrypted connections on port 5671. To opt-out of this default,
+# set the rabbitmq_use_ssl variable to 'false'. The default setting of 'true'
+# is highly recommended for securing the contents of RabbitMQ messages.
+# rabbitmq_use_ssl: false
+
+# RabbitMQ management plugin is enabled by default, the guest user has been
+# removed for security reasons and a new userid 'monitoring' has been created
+# with the 'monitoring' user tag. In order to modify the userid, uncomment the
+# following and change 'monitoring' to your userid of choice.
+# rabbitmq_monitoring_userid: monitoring
+
+
+## Additional pinning generator that will allow for more packages to be pinned as you see fit.
+## All pins allow for package and versions to be defined. Be careful using this as versions
+## are always subject to change and updates regarding security will become your problem from this
+## point on. Pinning can be done based on a package version, release, or origin. Use "*" in the
+## package name to indicate that you want to pin all package to a particular constraint.
+# apt_pinned_packages:
+# - { package: "lxc", version: "1.0.7-0ubuntu0.1" }
+# - { package: "libvirt-bin", version: "1.2.2-0ubuntu13.1.9" }
+# - { package: "rabbitmq-server", origin: "www.rabbitmq.com" }
+# - { package: "*", release: "MariaDB" }
+
+
+## Environment variable settings
+# This allows users to specify the additional environment variables to be set
+# which is useful in setting where you working behind a proxy. If working behind
+# a proxy It's important to always specify the scheme as "http://". This is what
+# the underlying python libraries will handle best. This proxy information will be
+# placed both on the hosts and inside the containers.
+
+## Example environment variable setup:
+## This is used by apt-cacher-ng to download apt packages:
+proxy_env_url: http://10.0.1.1:3128/
+
+## (1) This sets up a permanent environment, used during and after deployment:
+no_proxy_env: "localhost,127.0.0.1,{{ internal_lb_vip_address }},{{ external_lb_vip_address }},{% for host in groups['all_containers'] %}{{ hostvars[host]['container_address'] }}{% if not loop.last %},{% endif %}{% endfor %}"
+global_environment_variables:
+ HTTP_PROXY: "{{ proxy_env_url }}"
+ HTTPS_PROXY: "{{ proxy_env_url }}"
+ NO_PROXY: "{{ no_proxy_env }}"
+ http_proxy: "{{ proxy_env_url }}"
+ https_proxy: "{{ proxy_env_url }}"
+ no_proxy: "{{ no_proxy_env }}"
+#
+## (2) This is applied only during deployment, nothing is left after deployment is complete:
+deployment_environment_variables:
+ http_proxy: "{{ proxy_env_url }}"
+ https_proxy: "{{ proxy_env_url }}"
+ no_proxy: "localhost,127.0.0.1,{{ internal_lb_vip_address }},{{ external_lb_vip_address }},{% for host in groups['keystone_all'] %}{{ hostvars[host]['container_address'] }}{% if not loop.last %},{% endif %}{% endfor %}"
+
+
+## SSH connection wait time
+# If an increased delay for the ssh connection check is desired,
+# uncomment this variable and set it appropriately.
+#ssh_delay: 5
+
+
+## HAProxy and keepalived
+# All the previous variables are used inside a var, in the group vars.
+# You can override the current keepalived definition (see
+# group_vars/all/keepalived.yml) in your user space if necessary.
+#
+# Uncomment this to disable keepalived installation (cf. documentation)
+# haproxy_use_keepalived: False
+#
+# HAProxy Keepalived configuration (cf. documentation)
+# Make sure that this is set correctly according to the CIDR used for your
+# internal and external addresses.
+# haproxy_keepalived_external_vip_cidr: "{{external_lb_vip_address}}/32"
+# haproxy_keepalived_internal_vip_cidr: "{{internal_lb_vip_address}}/32"
+# haproxy_keepalived_external_interface:
+# haproxy_keepalived_internal_interface:
+
+# Defines the default VRRP id used for keepalived with haproxy.
+# Overwrite it to your value to make sure you don't overlap
+# with existing VRRPs id on your network. Default is 10 for the external and 11 for the
+# internal VRRPs
+# haproxy_keepalived_external_virtual_router_id:
+# haproxy_keepalived_internal_virtual_router_id:
+
+# Defines the VRRP master/backup priority. Defaults respectively to 100 and 20
+# haproxy_keepalived_priority_master:
+# haproxy_keepalived_priority_backup:
+
+# Keepalived default IP address used to check its alive status (IPv4 only)
+# keepalived_ping_address: "193.0.14.129"
+
+# Variable para habilitar la creación de imagenes en el Horizon en forma legacy
+horizon_images_upload_mode: "legacy"
diff --git a/taller/src/haproxy1/network-scripts/ifcfg-eth0 b/taller/src/haproxy1/network-scripts/ifcfg-eth0
new file mode 100644
index 0000000000000000000000000000000000000000..579a389dbd748290351323c7213ec64722ebe58f
--- /dev/null
+++ b/taller/src/haproxy1/network-scripts/ifcfg-eth0
@@ -0,0 +1,11 @@
+TYPE=Ethernet
+BOOTPROTO=none
+DEFROUTE=yes
+IPV4_FAILURE_FATAL=no
+NAME=etho
+DEVICE=eth0
+ONBOOT=yes
+IPADDR=10.0.1.15
+PREFIX=24
+GATEWAY=10.0.1.1
+DNS1=192.168.60.230
diff --git a/taller/src/haproxy1/network-scripts/ifcfg-eth1 b/taller/src/haproxy1/network-scripts/ifcfg-eth1
new file mode 100644
index 0000000000000000000000000000000000000000..54d9a9cba5a0c72b92452941de0c46c750c7194e
--- /dev/null
+++ b/taller/src/haproxy1/network-scripts/ifcfg-eth1
@@ -0,0 +1,9 @@
+TYPE=Ethernet
+BOOTPROTO=none
+DEFROUTE=yes
+IPV4_FAILURE_FATAL=no
+NAME=eth1
+DEVICE=eth1
+ONBOOT=yes
+IPADDR=192.168.60.160
+PREFIX=24
diff --git a/taller/src/infra1/network-scripts/ifcfg-br-mgmt b/taller/src/infra1/network-scripts/ifcfg-br-mgmt
new file mode 100644
index 0000000000000000000000000000000000000000..d3dec042490fdfebadc298a9693f5b831ef785e0
--- /dev/null
+++ b/taller/src/infra1/network-scripts/ifcfg-br-mgmt
@@ -0,0 +1,9 @@
+DEVICE=br-mgmt
+BOOTPROTO=none
+IPADDR=10.0.1.11
+PREFIX=24
+GATEWAY=10.0.1.1
+DNS1=192.168.60.230
+ONBOOT=yes
+TYPE=Bridge
+NM_CONTROLLED=no
diff --git a/taller/src/infra1/network-scripts/ifcfg-br-storage b/taller/src/infra1/network-scripts/ifcfg-br-storage
new file mode 100644
index 0000000000000000000000000000000000000000..f82c00fa81d887ba1d183621861625b135ecc33f
--- /dev/null
+++ b/taller/src/infra1/network-scripts/ifcfg-br-storage
@@ -0,0 +1,7 @@
+DEVICE=br-storage
+BOOTPROTO=none
+IPADDR=10.0.2.11
+PREFIX=24
+ONBOOT=yes
+TYPE=Bridge
+NM_CONTROLLED=no
diff --git a/taller/src/infra1/network-scripts/ifcfg-br-vxlan b/taller/src/infra1/network-scripts/ifcfg-br-vxlan
new file mode 100644
index 0000000000000000000000000000000000000000..23039a1493b70f18995576b7ec3f6a7668c530f2
--- /dev/null
+++ b/taller/src/infra1/network-scripts/ifcfg-br-vxlan
@@ -0,0 +1,7 @@
+DEVICE=br-vxlan
+BOOTPROTO=none
+IPADDR=10.0.10.11
+PREFIX=24
+ONBOOT=yes
+TYPE=Bridge
+NM_CONTROLLED=no
diff --git a/taller/src/infra1/network-scripts/ifcfg-eth0 b/taller/src/infra1/network-scripts/ifcfg-eth0
new file mode 100644
index 0000000000000000000000000000000000000000..516f94c2284d364fb596de0763e22aa17378c2c1
--- /dev/null
+++ b/taller/src/infra1/network-scripts/ifcfg-eth0
@@ -0,0 +1,6 @@
+TYPE="Ethernet"
+BOOTPROTO=none
+DEVICE=eth0
+ONBOOT=yes
+NM_CONTROLLED=no
+BRIDGE=br-mgmt
diff --git a/taller/src/infra1/network-scripts/ifcfg-eth1 b/taller/src/infra1/network-scripts/ifcfg-eth1
new file mode 100644
index 0000000000000000000000000000000000000000..bda8690c215c11338b32901bb44c2308fb2ac66e
--- /dev/null
+++ b/taller/src/infra1/network-scripts/ifcfg-eth1
@@ -0,0 +1,6 @@
+TYPE="Ethernet"
+BOOTPROTO=none
+DEVICE=eth1
+ONBOOT=yes
+NM_CONTROLLED=no
+BRIDGE=br-storage
diff --git a/taller/src/infra1/network-scripts/ifcfg-eth2 b/taller/src/infra1/network-scripts/ifcfg-eth2
new file mode 100644
index 0000000000000000000000000000000000000000..1fcbbc9656bc6a98724320f03aee30a50116dde2
--- /dev/null
+++ b/taller/src/infra1/network-scripts/ifcfg-eth2
@@ -0,0 +1,6 @@
+TYPE="Ethernet"
+BOOTPROTO=none
+DEVICE=eth2
+ONBOOT=yes
+NM_CONTROLLED=no
+BRIDGE=br-vxlan
diff --git a/taller/src/infra1/network-scripts/ifcfg-eth3 b/taller/src/infra1/network-scripts/ifcfg-eth3
new file mode 100644
index 0000000000000000000000000000000000000000..304aba6df83d5e37db8e2a8c07a37375ff3e4925
--- /dev/null
+++ b/taller/src/infra1/network-scripts/ifcfg-eth3
@@ -0,0 +1,7 @@
+TYPE="Ethernet"
+BOOTPROTO=none
+DEVICE="eth3"
+NAME="eth3"
+ONBOOT=yes
+NM_CONTROLLED=no
+
diff --git a/taller/src/renata/sshd_config b/taller/src/renata/sshd_config
new file mode 100644
index 0000000000000000000000000000000000000000..215a63e862b05d60daa754361fc51d1ad0b6d251
--- /dev/null
+++ b/taller/src/renata/sshd_config
@@ -0,0 +1,145 @@
+# $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $
+
+# This is the sshd server system-wide configuration file. See
+# sshd_config(5) for more information.
+
+# This sshd was compiled with PATH=/usr/local/bin:/usr/bin
+
+# The strategy used for options in the default sshd_config shipped with
+# OpenSSH is to specify options with their default value where
+# possible, but leave them commented. Uncommented options override the
+# default value.
+
+# If you want to change the port on a SELinux system, you have to tell
+# SELinux about this change.
+# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
+#
+#Port 22
+#AddressFamily any
+#ListenAddress 0.0.0.0
+#ListenAddress ::
+
+HostKey /etc/ssh/ssh_host_rsa_key
+#HostKey /etc/ssh/ssh_host_dsa_key
+HostKey /etc/ssh/ssh_host_ecdsa_key
+HostKey /etc/ssh/ssh_host_ed25519_key
+
+# Ciphers and keying
+#RekeyLimit default none
+
+# Logging
+#SyslogFacility AUTH
+SyslogFacility AUTHPRIV
+#LogLevel INFO
+
+# Authentication:
+
+#LoginGraceTime 2m
+PermitRootLogin no
+#StrictModes yes
+#MaxAuthTries 6
+#MaxSessions 10
+
+#PubkeyAuthentication yes
+
+# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
+# but this is overridden so installations will only check .ssh/authorized_keys
+AuthorizedKeysFile .ssh/authorized_keys
+
+#AuthorizedPrincipalsFile none
+
+#AuthorizedKeysCommand none
+#AuthorizedKeysCommandUser nobody
+
+# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
+#HostbasedAuthentication no
+# Change to yes if you don't trust ~/.ssh/known_hosts for
+# HostbasedAuthentication
+#IgnoreUserKnownHosts no
+# Don't read the user's ~/.rhosts and ~/.shosts files
+#IgnoreRhosts yes
+
+# To disable tunneled clear text passwords, change to no here!
+#PasswordAuthentication yes
+#PermitEmptyPasswords no
+PasswordAuthentication yes
+
+# Change to no to disable s/key passwords
+#ChallengeResponseAuthentication yes
+ChallengeResponseAuthentication no
+
+# Kerberos options
+#KerberosAuthentication no
+#KerberosOrLocalPasswd yes
+#KerberosTicketCleanup yes
+#KerberosGetAFSToken no
+#KerberosUseKuserok yes
+
+# GSSAPI options
+GSSAPIAuthentication yes
+GSSAPICleanupCredentials no
+#GSSAPIStrictAcceptorCheck yes
+#GSSAPIKeyExchange no
+#GSSAPIEnablek5users no
+
+# Set this to 'yes' to enable PAM authentication, account processing,
+# and session processing. If this is enabled, PAM authentication will
+# be allowed through the ChallengeResponseAuthentication and
+# PasswordAuthentication. Depending on your PAM configuration,
+# PAM authentication via ChallengeResponseAuthentication may bypass
+# the setting of "PermitRootLogin without-password".
+# If you just want the PAM account and session checks to run without
+# PAM authentication, then enable this but set PasswordAuthentication
+# and ChallengeResponseAuthentication to 'no'.
+# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
+# problems.
+UsePAM yes
+
+#AllowAgentForwarding yes
+AllowAgentForwarding yes
+#AllowTcpForwarding yes
+AllowTcpForwarding yes
+#GatewayPorts no
+GatewayPorts yes
+X11Forwarding yes
+#X11DisplayOffset 10
+#X11UseLocalhost yes
+#PermitTTY yes
+#PrintMotd yes
+#PrintLastLog yes
+#TCPKeepAlive yes
+TCPKeepAlive yes
+#UseLogin no
+#UsePrivilegeSeparation sandbox
+#PermitUserEnvironment no
+#Compression delayed
+#ClientAliveInterval 0
+#ClientAliveCountMax 3
+#ShowPatchLevel no
+#UseDNS yes
+#PidFile /var/run/sshd.pid
+#MaxStartups 10:30:100
+#PermitTunnel no
+PermitTunnel yes
+#ChrootDirectory none
+#VersionAddendum none
+
+# no default banner path
+#Banner none
+
+# Accept locale-related environment variables
+AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
+AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
+AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
+AcceptEnv XMODIFIERS
+
+# override default of no subsystems
+Subsystem sftp /usr/libexec/openssh/sftp-server
+
+# Example of overriding settings on a per-user basis
+#Match User anoncvs
+# X11Forwarding no
+# AllowTcpForwarding no
+# PermitTTY no
+# ForceCommand cvs server
+
diff --git a/taller/src/storage1/network-scripts/ifcfg-br-mgmt b/taller/src/storage1/network-scripts/ifcfg-br-mgmt
new file mode 100644
index 0000000000000000000000000000000000000000..1cc8831ce7b8a624e73cc34211f2d059043963c1
--- /dev/null
+++ b/taller/src/storage1/network-scripts/ifcfg-br-mgmt
@@ -0,0 +1,9 @@
+DEVICE="br-mgmt"
+BOOTPROTO="none"
+IPADDR="10.0.1.13"
+PREFIX="24"
+GATEWAY="10.0.1.1"
+DNS1="192.168.60.230"
+ONBOOT="yes"
+TYPE="Bridge"
+NM_CONTROLLED="no"
diff --git a/taller/src/storage1/network-scripts/ifcfg-br-storage b/taller/src/storage1/network-scripts/ifcfg-br-storage
new file mode 100644
index 0000000000000000000000000000000000000000..debf326acf79c58db172888ecf13bb08365ece66
--- /dev/null
+++ b/taller/src/storage1/network-scripts/ifcfg-br-storage
@@ -0,0 +1,7 @@
+DEVICE="br-storage"
+BOOTPROTO="none"
+IPADDR="10.0.2.13"
+PREFIX="24"
+ONBOOT="yes"
+TYPE="Bridge"
+NM_CONTROLLED="no"
diff --git a/taller/src/storage1/network-scripts/ifcfg-eth0 b/taller/src/storage1/network-scripts/ifcfg-eth0
new file mode 100644
index 0000000000000000000000000000000000000000..bcaf39a640d8e107bfb1bb853d9be1f88039065d
--- /dev/null
+++ b/taller/src/storage1/network-scripts/ifcfg-eth0
@@ -0,0 +1,7 @@
+TYPE="Ethernet"
+BOOTPROTO="none"
+NAME="eth0"
+DEVICE="eth0"
+ONBOOT="yes"
+NM_CONTROLLED=no
+BRIDGE="br-mgmt"
diff --git a/taller/src/storage1/network-scripts/ifcfg-eth1 b/taller/src/storage1/network-scripts/ifcfg-eth1
new file mode 100644
index 0000000000000000000000000000000000000000..6276229f7c3c988e73ed798b33c8a96f855909c1
--- /dev/null
+++ b/taller/src/storage1/network-scripts/ifcfg-eth1
@@ -0,0 +1,7 @@
+TYPE="Ethernet"
+BOOTPROTO="none"
+NAME="eth1"
+DEVICE="eth1"
+ONBOOT="yes"
+NM_CONTROLLED=no
+BRIDGE="br-storage"