From f7c0347e43536c1a5a7b16cebce9a90ad1e3949c Mon Sep 17 00:00:00 2001
From: mcapucho <matias.capucho@fing.edu.uy>
Date: Mon, 27 Jan 2020 18:33:28 -0300
Subject: [PATCH] =?UTF-8?q?-=20Introducci=C3=B3n=20dise=C3=B1o?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 "docs/udelartex/capitulos/dise\303\261o.tex"   | 1 +
 docs/udelartex/capitulos/openstack-ansible.tex | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git "a/docs/udelartex/capitulos/dise\303\261o.tex" "b/docs/udelartex/capitulos/dise\303\261o.tex"
index 3ab92f8..e68be8a 100644
--- "a/docs/udelartex/capitulos/dise\303\261o.tex"
+++ "b/docs/udelartex/capitulos/dise\303\261o.tex"
@@ -1,4 +1,5 @@
 \chapter{Diseño}
+En el siguiente capítulo se describen las diversas decisiones tomadas y las estructuras y diseños utilizados para realizar la instalación de OpenStack-Ansible. En capítulo se divide en dos secciones, hablando en una de ellas sobre las arquitecturas utilizadas tanto para desarrollo como producción y por otro lado las especificaciones y configuraciones realizadas para preparar el ambiente de trabajo. Debido a la flexibilidad que presenta OpenStack al momento de desplegar sus componentes entre nodos y contenedores, es de suma importancia evaluar cuales serán los requerimientos, analizando de que forma se utilizará y la magnitud del Datacenter.
 
 \section{Diseño de arquitectura}
 Los diseños que se presentan en esta sección están orientados a ser utilizados con servidores y componentes de red físicos. Debido a que no se cuenta con los suficientes recursos, todo el ambiente físico será virtualizado dentro de un único servidor detallado en la siguiente sección. De aquí en mas cada uno de los nodos virtualizados del Datacenter será considerado como un nodo físico, ademas los switches físicos necesarios serán emulados mediante Linux Bridges alojados en el servidor renata. Por último en el caso en que es necesario un router TOR se implemente mediante una VM que mantiene configurados los forwarding necesarios.
diff --git a/docs/udelartex/capitulos/openstack-ansible.tex b/docs/udelartex/capitulos/openstack-ansible.tex
index 273ffaf..94f9f0c 100644
--- a/docs/udelartex/capitulos/openstack-ansible.tex
+++ b/docs/udelartex/capitulos/openstack-ansible.tex
@@ -1,5 +1,5 @@
 \chapter{OpenStack-Ansible}\label{cap:openstack-ansible}
-OpenStack-Ansible se trata de un proyecto basado en la herramienta de automatización Ansible para realizar el despliegue de la plataforma OpenStack. Dicho proyecto se encarga de proveer playbooks y roles para desplegar y configurar un ambiente basado en el concepto de Infrastructure as Code (IaC). 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 probado para ambientes de cualquier tamaño, desde Datacenters de testing hasta producción. Como fue mencionado en la sección \ref{sec:metodos-instalacion}, la utilización de una herramienta de esta índole no podía cuestionarse. Sin embargo, era relevante determinar cuál de todas las existentes utilizar. Para tomar la decisión se consultó con Edgar Magana, un arquitecturo de operaciones en la nube con amplio conocimiento de la plataforma OpenStack y allegado a los tutores, quién argumentó que OSA era la opción indicada para comenzar. En función de esto, en este capítulo se analiza la arquitectura, configuraciones y funcionamiento de OSA.
+OpenStack-Ansible se trata de un proyecto basado en la herramienta de automatización Ansible para realizar el despliegue de la plataforma OpenStack. Dicho proyecto se encarga de proveer playbooks y roles para desplegar y configurar un ambiente basado en el concepto de Infrastructure as Code (IaC). 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 probado para ambientes de cualquier tamaño, desde Datacenters de testing hasta producción. Como fue mencionado en la sección \ref{sec:metodos-instalacion}, la utilización de una herramienta de esta índole no podía cuestionarse. Sin embargo, era relevante determinar cuál de todas las existentes utilizar. Para tomar la decisión se consultó con Edgar Magana, un arquitecto de operaciones en la nube con amplio conocimiento de la plataforma OpenStack y allegado a los tutores, quién argumentó que OSA era la opción indicada para comenzar. En función de esto, en este capítulo se analiza la arquitectura, configuraciones y funcionamiento de OSA.
 
 
 \section{Arquitectura}
-- 
GitLab