Entorno-de-desarrollo-y-operaciones-(devops).md

@@ -61,9 +61,9 @@ El entorno devops aquí en cuestión se despliega en un conjunto de servidores f
 
 Sin embargo, desde una misma fuente devops, también gestionamos varios recursos que están situados en las sedes de los CENURES distribuidas en todo el territorio nacional, e incluso los puntos de acceso de una red wifi del Campus Luisi Janicki se gestiona desde un contenedor desplegado de esta manera.
 
-### Red y direccionamiento
+### Red, direccionamiento & nombres
 
-La RAU nos ha delegado la gestión y enruta a nuestra infraestructura en el datacenter los siguientes direccionamientos de red:
+La RAU nos ha delegado la gestión y enruta a nuestra infraestructura en el datacenter [los siguientes direccionamientos de red](https://red.interior.edu.uy/ipam/prefixes/?tenant_group_id=1&tenant_id=2):
 * IPv4: **164.73.98.0/23**, que utilizamos:
   * **164.73.98.0/24** para la red de producción,
   * **164.73.99.0/24** para la red de stage.
@@ -71,19 +71,19 @@ La RAU nos ha delegado la gestión y enruta a nuestra infraestructura en el data
 
 Cabe mencionar que, en administración sólo se accede a esta red por VPN.
 
-Utilizamos para esta plataforma 
+El direccionamiento de nombres se construye en [la zona `interior.edu.uy`](https://git.interior.edu.uy/adminsys/config/-/blob/main/files/bind/zones/db.interior.edu.uy#L110), utilizando, para la nomenclatura de los dominios nombres canónicos de servidores (_hosts_) _palabras uruguayas_.
 
 ### Plataforma de virtualización Proxmox VE
 
 Si bien por el Litoral estamos probando Kubernetes, para implementar nuestra plataforma de computación en la nube escogimos la solución de virtualización [_Proxmox Virtual Environement_](https://pve.proxmox.com/) (PVE), que integra tecnologías como contenedores LXE, maquinas virtuales qemu/KVM, discos LVM thin (y otras que no utilizamos, como Ceph).
 
 En el rack de SeCIU gestionamos dos clusters PVE:
-* un cluster de producción que comprende:
+* <a name="cluster_prod"></a>un cluster de producción que comprende:
   * `botija` y `gurí`: servidores aplicativos, con buena capacidad de memoria y procesamiento, con 8Tb de almacenamiento SSD
   * `redota`: servidor de respaldon y almacenamiento, con 50Tb SATA
   * `guyunusa`: servidor aplicativo de menor capacidad, adquirido por la SECEAM, que hospeda la mayoría de servicios no directamente vinculados al Interior.
 
-* un cluster de stage, con dos servidores de recuperación, `mate` y `carpincho`
+* un cluster de stage, con dos servidores de recuperación, `mate` y `carpincho` (__todo__)
 
 # Automatización de la configuración
 
@@ -95,12 +95,20 @@ El repo central de nuestra IaC es [git.interior.edu.uy/adminsys/config](https://
 
 Usamos el software libre compartido en la [Ansible Galaxy](https://galaxy.ansible.com/), a la que también contribuimos activamente, aportando a roles existentes o compartiendo nuestros propios roles y colecciones, inicialmente en [github.com/udelaRInterior/](https://github.com/udelaRInterior/) y, ahora que se puede, en nuestro propio gitlab, en particular acá: https://git.interior.edu.uy/cielito
 
-Lo puedes ver en 
+Puedes ver los roles que usamos en el [`requirements.yml` de la IaC ansible](https://git.interior.edu.uy/adminsys/config/-/blob/main/requirements.yml).
 
-## Nuestro inventario
+## Nuestro inventario ansible-PVE
 
 Manejamos actualmente dos inventarios ansible estáticos:
-* [host_stage](https://git.interior.edu.uy/adminsys/config/-/blob/main/hosts_stage), que será el inventario por omisión al ejecutar un playbook desde una réplica 
+* [host_stage](https://git.interior.edu.uy/adminsys/config/-/blob/main/hosts_stage), inventario de _stage_ donde referenciamos los areneros de nuestra infra. Será el inventario por omisión al ejecutar un playbook desde una réplica del repo, en una cuenta personal con claves y derechos necesarios,
+* [host_prod](https://git.interior.edu.uy/adminsys/config/-/blob/main/host_prod), inventario de _producción_ donde se describe [el cluster PVE de producción](#cluster_prod), con sus nodos virtuales KVM y sus contenedores LXC. Para usar este inventario, debemos indicarlo explícitamente al tirar un playbook ansible.
+
+Estos dos inventarios comparten (o deberían compartir, tenemos refactor en curso adminsys/config#390) buena parte su estructura de grupos, difiriendo esencialmente en el un sub-nivel:
+* el primer nivel es el del _site_, la localización física. ahora en la rama main manejamos todo en `seciu`, pero llegamos a gestionar cosas de `csic` y en [una rama](https://git.interior.edu.uy/adminsys/config/-/blob/124-empezar-a-manejar-los-servidores-del-cure-con-ansible/hosts_prod#L104)  (que ya es un árbol en sí) se maneja la infra del `cure`.
+*  el segundo o tercer nivel es el del cluster PVE: el inventario de stage menciona y distingue la infraestructura de stage y (parte de) la de prod. A la inversa, la prod sólo menciona un conjunto de nodos que conforman _el_ cluster. Esto es porque, como explicado más arriba, no todos los areneros están en una infraestructura de stage, algunos usan recursos de prod. El stage ve la prod, la prod no ve el stage.
+* el resto de la estructura de grupos, en particular los funcionales y varios grupos de grupos que sirven para delimitar alcances de plays, procuran ser compartidos entre prod y stage, de manera a compartir código de orquestación ansible.
+
+El disponer así de dos grupos específicos a la IaC de stage, `seciu_prod` y `seciu_stage`, los dos diferentes de la IaC de prod, que solo conoce `seciu_nodos`, permite acceder con credenciales diferentes según el contexto.
  
 
 ## Introducción a nuestro flujo de trabajo