Un planificador que no incorporará nada

Incorporar un nuevo servicio a mi homelab es repetitivo: clasificar qué es, decidir dónde vive, determinar si necesita una base de datos, un destino de respaldo, un monitor, una ruta, un registro DNS, y cuáles de esos son realmente críticos. Es justo el tipo de trabajo que invita a la automatización, y justo el tipo de trabajo donde la automatización falla silenciosamente.

Así que se divide en dos, y la división está en el verbo.

El Nivel 4A clasifica y planea. No puede actuar.

El planificador lee registros candidatos, los clasifica y escribe un plan local para el operador — JSON y Markdown, en un directorio de tiempo de ejecución. Esa es toda su capacidad. No crea contenedores, no escribe archivos compose, no registra DNS ni toca un host. Incluso su propia escritura es optativa detrás de una bandera de aplicar; sin ella, la herramienta imprime lo que habría escrito.

El ejecutor es un nivel separado, con un control separado, que requiere un registro de aprobación duradero que nombre el plan exacto sobre el que se le permite actuar. La ejecución en vivo está deshabilitada por defecto.

Habilitar un candidato es un cambio de nombre

Los registros candidatos viven como archivos en un directorio. Se escanean los archivos que terminan en las extensiones de datos normales; los archivos que terminan en .disabled no se escanean.

Esto significa que el acto de promover un ejemplo a candidato activo es un cambio de nombre de archivo, que aparece en un diff como un cambio de nombre, en un pull request como un cambio revisable, y en el historial del repositorio como un evento fechado con autor.

Me gusta esto mucho más que un campo booleano dentro del archivo. Una bandera habilitada que cambia de false a true es un carácter en un diff, fácil de pasar por alto en la revisión e imposible de ver en un listado de directorio. Un cambio de nombre es visible desde fuera del archivo. Cuando construyes algo cuya seguridad depende de que los humanos noten, el interruptor debería estar en un lugar donde un humano ya esté mirando.

Por qué solo planificar no es una medida a medias

Sigo encontrando la suposición de que un sistema que planea pero no actúa está incompleto — un paso hacia la autonomía. En mi homelab es lo contrario. El cuello de botella nunca fue mi capacidad para ejecutar comandos. Fue saber qué comandos valía la pena ejecutar.

Una herramienta que me entrega un plan correcto, citado y completo ha eliminado la parte en la que soy malo. Ejecutarlo toma minutos y soy bueno en eso. Automatizar la mitad en la que soy bueno, para ahorrar la mitad en la que no lo soy, sería el intercambio incorrecto — y gastaría todo el presupuesto de seguridad del sistema en el paso menos valioso.