Manifests

Cada Workload que creas en SleakOps se despliega en Kubernetes a través de un conjunto de manifiestos — los recursos Deployment, Service, Ingress, PodDisruptionBudget y HorizontalPodAutoscaler que SleakOps genera para él. La funcionalidad de Manifests convierte esos recursos en ciudadanos de primera clase: puedes inspeccionar cada uno, personalizar su YAML, deshabilitarlo o agregar tus propios manifiestos extra — por Workload o compartidos a nivel del Project.

Disponibilidad

Manifests se está habilitando progresivamente. Si no ves el toggle Advanced en los formularios de tus Workloads ni la sección Manifests en la Chart Configuration de tu Project, la funcionalidad todavía no está habilitada para tu compañía.

Dónde encontrarlos

Los manifiestos viven en dos lugares:

• Por Workload — abre cualquier Workload (WebService, Worker, CronJob o Hook) y cambia el toggle de vista de Form a Advanced. La vista Advanced tiene dos tabs: Manifests (el grafo de recursos) y Values (ver Values).
• Por Project — ve a Project → Settings → Chart Configuration. La sección Manifests lista todos los Workloads y manifiestos del Project, y administra el project bucket compartido.

La vista Form sigue siendo la fuente de verdad de la configuración de tu Workload: un submit actualiza todos los manifiestos generados. La vista Advanced es donde inspeccionas y personalizas lo que se despliega.

El grafo de manifiestos

El tab Manifests muestra los recursos del Workload como un grafo, donde las aristas representan las relaciones entre ellos:

Cada nodo muestra el nombre del manifiesto, su Kind (o el host resuelto, en los Ingress) y su origen:

Origen	Badge	Significado
Managed	Managed	Generado y mantenido al día por SleakOps. Las actualizaciones del template base se aplican solas.
Customized	Customized	Editaste su YAML. SleakOps nunca sobreescribe tu copia — ver actualizaciones del template base.
Custom	Custom	Un manifiesto que agregaste tú. No tiene template base de SleakOps.

Los manifiestos deshabilitados muestran un badge Disabled y sus aristas se dibujan punteadas.

Puedes arrastrar los nodos para acomodar el grafo — las posiciones se guardan por Workload, y Reset layout restaura el orden automático.

Debajo del grafo, la franja Project-shared manifests muestra los manifiestos del project bucket que se despliegan junto a todos los Workloads, con un acceso Manage → a la Chart Configuration del Project.

Editar un manifiesto

Haz clic en cualquier nodo para abrir el editor. El header muestra el kind del manifiesto, su origen, la versión del template base, un switch Enabled, un botón de copiado y Delete.

El tab YAML es donde editas el template. Pueden aparecer dos tipos de placeholders:

• Las variables << form >> se resuelven antes de Helm, con los valores del formulario de tu Workload (nombre, namespace, command, healthcheck, etc.).
• Las expresiones {{ .Values }} quedan para Helm en el momento del deploy (replicas, resources, tag de imagen — todo lo que viene de Values).

El panel Variables de la derecha lista todo lo disponible: haz clic en una entrada para insertarla en el cursor, o arrástrala al editor.

El editor valida mientras escribes. Los errores bloquean el guardado, e incluyen:

• Variables desconocidas, no declaradas en el contexto del Workload.
• Expresiones bloqueadas por el sandbox de templates.
• Quitar el label protegido sleakops.com/managed.
• Un namespace distinto al del entorno del Project (warning — el namespace siempre es el del entorno).

Guardar tu primera edición estructural convierte un manifiesto managed en customized. Si el switch Deploy? de la toolbar del grafo está apagado, el guardado queda registrado como un cambio pendiente; si está prendido, se dispara un deployment al instante.

Preview

El tab Preview renderiza el template con las variables actuales del formulario y muestra exactamente lo que se le entregará a Helm:

Los badges sobre la salida confirman cuántas variables << form >> se resolvieron, si quedan expresiones {{ .Values }} para el deploy, y que los invariantes protegidos están presentes. Si el template no renderiza, los errores se listan con su número de línea y un acceso Fix in YAML — un manifiesto que no renderiza no se despliega.

Agregar un manifiesto

Usa Add manifest (en la toolbar del grafo del Workload, o en el project bucket) para desplegar recursos más allá de los generados:

Campo	Descripción
Scope	This workload (se despliega con el Workload, con variables << form >> disponibles) o Project bucket (compartido, se despliega con cada release).
Kind	ConfigMap, Secret, ServiceAccount, NetworkPolicy, PersistentVolumeClaim, CronJob — o Custom… para cualquier otro kind, incluidos CRDs.
Name	El nombre del manifiesto; se refleja en el metadata.name del template.
Depends on	Opcional. Dibuja las aristas del grafo desde este manifiesto hacia los seleccionados.
Template	El YAML del manifiesto. Se genera un stub inicial según el Kind elegido.

Ten en cuenta:

• Los kinds cluster-scoped se rechazan, y el namespace debe ser igual al del entorno del Project.
• Los kinds custom requieren su CRD instalado en el cluster — por ejemplo, un ScaledObject de Keda necesita el Addon de Keda. Si no, el deploy falla con el error correspondiente de Helm.

El project bucket

Los manifiestos agregados con scope Project bucket no están atados a ningún Workload: se despliegan con cada release del Project. Los habitantes típicos son NetworkPolicies, ConfigMaps compartidos y ServiceAccounts. Se administran desde Project → Settings → Chart Configuration → Manifests:

El Explorer al inicio de la sección lista cada Workload del Project con sus manifiestos, y el project bucket al final. Usa el filtro para buscar por nombre o kind; hacer clic en un Workload abre su vista Advanced, y hacer clic en un manifiesto abre el editor ahí mismo.

Extends Template & Values está deprecado

La sección libre Extends Template & Values debajo de Manifests sigue funcionando, pero está deprecada: los recursos custom nuevos deberían agregarse como manifiestos. Ver Extra Templates.

Actualizaciones del template base

Cuando personalizas un manifiesto, tu copia queda fijada: SleakOps nunca la sobreescribe, incluso cuando el template base del que salió recibe mejoras. Cuando existe una versión base más nueva, el editor muestra un badge update available y un banner con un botón View diff:

• Las líneas verdes son lo que agrega la base nueva.
• Las líneas rojas son tus personalizaciones, ausentes de la base.

Desde el diff puedes elegir Keep my version o Reset to v<nueva>. Reset to base (también disponible en el header del editor) descarta tus ediciones estructurales, restaura el template base de SleakOps y vuelve el manifiesto a managed. Los valores del formulario no se ven afectados — solo rellenan variables.

Deshabilitar y borrar

• Deshabilitar (el switch Enabled): el manifiesto se saltea en el próximo deploy pero conserva su configuración. Si el recurso ya estaba desplegado, el próximo deploy lo quita del cluster.
• Delete: el manifiesto deja de desplegarse y SleakOps no lo vuelve a crear en futuros seeds ni actualizaciones del template base. Puedes agregar un manifiesto equivalente más adelante.

Desplegar tus cambios

Todos los cambios de contenido de la vista Manifests respetan el switch Deploy? de la toolbar:

• Prendido — se dispara un deployment después de cada guardado.
• Apagado — los cambios se acumulan como cambios pendientes y se despliegan cuando los publicas.

Las acciones de solo layout — arrastrar nodos o Reset layout — son cosméticas: nunca crean un cambio pendiente ni un deployment, esté como esté el switch.

FAQs

¿Puedo modificar los templates que genera SleakOps?

Sí. Abre la vista Advanced del Workload, haz clic en el manifiesto y edita su YAML. Tu copia pasa a customized y SleakOps nunca la sobreescribe.

¿Qué pasa con mis Extra Templates existentes?

Se siguen desplegando exactamente igual que antes. La sección Extends Template & Values quedó deprecada en favor de Manifests, así que migra los recursos custom a manifiestos a medida que los toques — un manifiesto por recurso, con validación y preview en lugar de un único bloque libre.

¿Puedo desplegar recursos de un CRD?

Sí — elige Custom… como Kind al agregar un manifiesto y define el apiVersion/kind del CRD. El CRD debe estar instalado en el cluster (por ejemplo, el ScaledObject de Keda requiere el Addon de Keda); si no, el deploy falla con el error correspondiente de Helm.

¿Por qué no puedo cambiar el namespace de un manifiesto?

Cada entorno del Project se despliega en su propio Namespace de Kubernetes. Los manifiestos siempre se despliegan en el namespace del entorno — un valor distinto se rechaza para mantener los entornos aislados.

¿Cuál es la diferencia entre deshabilitar y borrar un manifiesto?

Deshabilitar conserva el manifiesto y su configuración pero lo saltea al desplegar — vuelve a prender el switch para reincluirlo. Borrar lo quita definitivamente: SleakOps no lo recrea en futuras actualizaciones, aunque siempre puedes agregar un manifiesto nuevo con el mismo contenido.

¿Quién puede editar manifiestos?

La edición sigue tu rol en la plataforma: los viewers ven el grafo, el YAML y los previews en modo solo lectura; los editors y admins pueden personalizar, agregar, deshabilitar y borrar manifiestos.