Arquitectura

Mentat esta pensado como una plataforma privada de workloads con un control plane pequeno, un agent por host y un CLI para operacion. La meta es mantener deploy, scheduling, health y ciclo de vida en un solo sistema sin arrastrar la complejidad operativa de una plataforma mas pesada.

Que Corre Donde

Modelo Operativo

La arquitectura esta optimizada para infraestructura privada. El server decide donde debe correr un workload, el agent lo materializa en el host, y el CLI se mantiene liviano. Asi el control plane sigue pequeno pero soporta runtimes mixtos y workflows de deploy.

1. Operador ejecuta: mt run services.yaml
2. CLI valida el archivo y envia el job a mentat-server
3. Server guarda el estado deseado y elige un nodo
4. Server despacha una asignacion a mentat-agent
5. Agent inicia el workload con el driver seleccionado
6. Server guarda el estado observado y responde al operador

Saber Que Esta Mal

Un monitor de salud prueba cada endpoint registrado cada 10 segundos y escribe una conclusion en el registro: healthy, starting, unhealthy. Pasado un umbral de fallos consecutivos reinicia el workload a traves del agente, con un cooldown para que un boot lento no se convierta en una tormenta de reinicios.

La conclusion sola rara vez alcanza durante un incidente — dice que, no por que. Por eso los contadores detras tambien se pueden leer: cuantos probes fallaron seguidos, si hay un restart en vuelo, hace cuanto se reinicio el servicio por ultima vez, y la condicion del nodo donde vive cada endpoint. mt diagnose lee eso, vuelve a probar los endpoints en el momento, trae la salida reciente del workload por el agente, y reporta hallazgos. Todo ese camino es read-only, que es lo que lo hace seguro de correr cuando algo ya esta roto.

mt://services/{name}/health     status + los contadores detras
mt://services/{name}/diagnose  lo anterior + probes en vivo, logs, hallazgos
mt://nodes                     condiciones de lifecycle por nodo
mt://registry                  todos los endpoints que registro el agente

Un workload arrancado fuera del agente es invisible aca: el agente registra solo lo que el mismo lanzo, el ingress rutea solo lo que el registro conoce, y un puerto que responde en el host no prueba ninguna de las dos cosas. Esa brecha es, ella misma, uno de los hallazgos que mt diagnose reporta.

Por Que Esta Forma

Modelo de Definicion de Servicios

Los servicios declaran runtime, recursos, constraints y estrategia de deploy en una sola especificacion. Ese mismo modelo atraviesa scheduling, rollout y status.

pub enum Driver { Firecracker, Sandbox, Docker, Exec, Hull }

pub enum DeployStrategy { Rolling, BlueGreen, Canary }

pub enum DriverConfig {
    Firecracker(FirecrackerConfig),
    Sandbox(SandboxConfig),
    Docker(DockerConfig),
    Exec(ExecConfig),
    Hull(HullConfig),
}

pub struct ServiceSpec {
    pub name: String,
    pub replicas: u32,
    pub config: DriverConfig,
    pub resources: Resources,
    pub constraints: Vec<Constraint>,
    pub deploy: DeployConfig,
}

Stack de Implementacion