Saltar a contenido

O7 - Metadata Platform Foundation

Fecha: 2026-06-01

Objetivo

Disenar la base tecnologica de una futura plataforma de conocimiento para OpenClaw sin asumir nada y sin instalar nada todavia.

SAFE POINT inicial

  • git status -sb -> ## main...origin/main
  • git rev-parse HEAD -> 5bb4e45939182e99e26921d2feedefb26cbf78db

Fuentes de evidencia usadas

Repo y VPS

  • docs/VPS-INVENTORY.md
  • docs/PROJECT-STATE.md
  • docs/governance/operations/O6.0-REALITY-AUDIT.md
  • docker/openclaw/docker-compose.yml
  • infra/observability/docker-compose.yml
  • ssh openclaw-vps "hostname && date --iso-8601=seconds && nproc && free -h && df -h / && docker --version && docker compose version && docker ps ... && docker volume ls && docker network ls"
  • ssh openclaw-vps "docker ps -a ... | grep -i postgres || true; docker volume ls | grep -i postgres || true; ss -ltnp | grep 5432 || true"

OpenMetadata oficial

  • Minimum Requirements: https://docs.open-metadata.org/latest/deployment/minimum-requirements
  • Docker Deployment: https://docs.open-metadata.org/latest/deployment/docker
  • Local Docker Deployment: https://docs.open-metadata.org/latest/quick-start/local-docker-deployment
  • Metrics: https://docs.open-metadata.org/latest/deployment/metrics
  • Grafana connector: https://docs.open-metadata.org/v1.12.x/connectors/dashboard/grafana/yaml
  • Official Docker Compose release reviewed: https://github.com/open-metadata/OpenMetadata/releases/download/1.12.6-release/docker-compose-postgres.yml

Fase 0 - Diagnostico de OpenMetadata

Realidad actual del VPS observada

Item Evidencia actual
Host srv977009
CPU 2 vCPU
RAM 7.8 GiB
Disco / 96G total, 14G usados, 83G libres
Docker 29.1.3
Docker Compose v5.1.4
Contenedores activos 13
PostgreSQL actual no observado
Grafana actual obs-grafana, 127.0.0.1:3000->3000
Prometheus actual obs-prometheus, puerto interno 9090

Requisitos oficiales observados

Dependencias de producto

OpenMetadata documenta que requiere:

  • base de datos MySQL o PostgreSQL
  • motor de busqueda ElasticSearch u OpenSearch
  • orquestador para ingestion programada, tipicamente Airflow

Requisitos minimos oficiales

Componente Requisito oficial observado
Docker 20.10.0 o mayor
Docker Compose v2.2.3 o mayor
PostgreSQL 12.0 o mayor
Base de datos recomendacion minima 4 vCPU, 16 GiB, 100 GB
ElasticSearch/OpenSearch recomendacion minima 2 vCPU, 8 GiB, 100 GB por nodo
Airflow recomendacion minima 4 vCPU, 16 GiB, 100 GB
Quickstart local al menos 4 vCPU y 6 GiB para Docker

Arquitectura oficial observada

Del compose oficial y la documentacion se observa esta arquitectura minima:

  • openmetadata-server
  • execute-migrate-all
  • postgresql o base externa
  • elasticsearch u opensearch
  • ingestion para Airflow / ingestion framework

Puertos observados en el compose oficial revisado:

  • 8585: UI y API de OpenMetadata
  • 8586: admin port y health/metrics
  • 8080: contenedor de ingestion
  • 5432: PostgreSQL
  • 9200 y 9300: ElasticSearch

Recursos necesarios vs VPS actual

Criterio OpenMetadata oficial VPS actual Compatibilidad
CPU quickstart 4 vCPU; DB 4; Airflow 4; search 2 2 vCPU NO para produccion en el mismo VPS
RAM quickstart 6 GiB; DB 16; Airflow 16; search 8 7.8 GiB NO para stack completo conviviente
Disco DB 100 GB; search 100 GB por nodo 83 GB libres en / NO para baseline productiva recomendada
Docker >= 20.10.0 29.1.3 SI
Docker Compose >= v2.2.3 v5.1.4 SI

Compatibilidad con Docker actual

  • compatible por version de motor y Compose
  • no compatible por capacidad del host para correr el stack completo en este VPS junto con OpenClaw, NPM, Portainer y observability
  • el compose oficial ademas agregaria nuevos puertos y nuevos contenedores con estado persistente

Compatibilidad con Grafana actual

  • OpenMetadata tiene conector oficial Grafana para ingerir dashboards
  • el Grafana actual ya existe y esta restringido a 127.0.0.1:3000
  • por lo tanto la compatibilidad funcional existe, pero hoy no hay ruta documentada ni token de servicio versionado para esa integracion
  • conclusion: compatible a futuro, no conectado hoy

Compatibilidad con Prometheus actual

  • OpenMetadata publica metricas Prometheus en /prometheus sobre el admin port 8586
  • el EVENT_MONITOR oficial observado en compose viene en modo prometheus
  • por lo tanto el Prometheus actual podria scrapear OpenMetadata si algun dia existiera el servicio
  • conclusion: compatible a futuro, no conectado hoy

Compatibilidad con PostgreSQL

  • OpenMetadata soporta PostgreSQL 12+
  • en el VPS actual no se observo ningun contenedor PostgreSQL, volumen PostgreSQL ni listener en 5432
  • el catalogo actual de bases del repo solo registra SQLite de OpenClaw, NPM y base binaria propia de Portainer
  • conclusion: compatible en abstracto, ausente en la realidad actual

Veredicto de Fase 0

  • OpenMetadata es tecnicamente compatible con el ecosistema Docker actual por version
  • OpenMetadata no es compatible con el presupuesto real de recursos del VPS actual para un despliegue prudente en el mismo host
  • hoy tampoco existe la dependencia PostgreSQL requerida ni el motor de busqueda requerido
  • decision basada en evidencia: NO instalar OpenMetadata en este VPS en esta etapa

Fase 1 - Diseno de integracion

Donde vivira OpenMetadata

Decision actual

No vivira en srv977009 en esta etapa.

Ubicacion futura recomendada

Si algun dia se aprueba, O7 deberia vivir en una de estas dos formas:

  1. VPS separado para metadata con sus propias dependencias
  2. servicios gestionados externos para PostgreSQL + ElasticSearch/OpenSearch y un runtime dedicado para openmetadata-server + ingestion

Que almacenara

Si se implementa en el futuro, deberia almacenar solo metadata curada:

  • inventario de componentes
  • ownership y tags
  • relaciones entre host, servicio, contenedor, red, volumen y puerto
  • links a runbooks, dashboards y alertas
  • catalogo tecnico de infraestructura
  • lineage tecnico entre OpenClaw, proxy, observabilidad y persistencia

Que NO almacenara

  • secretos reales
  • archivos de backup
  • contenido crudo de volumenes Docker
  • TSDB de Prometheus
  • object store de Thanos
  • dashboards JSON fuente de verdad
  • logs crudos
  • docker.sock
  • contenido conversacional o memoria del agente sin una aprobacion explicita

Como convivira con O6

Regla de convivencia

Mientras O7 no exista en runtime, la autoridad sigue siendo O6.

Modelo de convivencia futura

  • O6 sigue como fuente humana y auditable
  • O7 se alimenta desde exportes o conectores controlados
  • la realidad siempre se revalida por SSH, Docker y repo antes de promover cambios al catalogo
  • si O7 contradice O6 y no hay evidencia nueva, gana O6

Fase 2 - Primer caso de uso

Caso modelado

OpenClaw Infrastructure Knowledge Base

Este caso de uso queda desarrollado en:

Alcance modelado con evidencia real

  • VPS
  • Docker
  • redes
  • volumenes
  • OpenClaw
  • Grafana
  • Prometheus
  • Thanos
  • Alertmanager
  • Portainer

Decision de valor real

El valor real demostrable hoy no es instalar un catalogo nuevo, sino dejar normalizado el modelo que O7 deberia absorber despues.

Fase 3 - Gobierno

Como crear nuevos proyectos

  1. abrir docs/governance/GOVERNANCE-RULES.md
  2. asignar IDs segun ID-CONVENTIONS.md
  3. crear ficha de servicio o uso compartido con las plantillas vigentes
  4. registrar red, volumen, puerto, dominio, backup y tests asociados
  5. agregar evidencia de realidad antes de cerrar

Como actualizar documentacion

  1. actualizar primero el documento de mayor autoridad del activo
  2. despues actualizar catalogos y navegacion
  3. anotar la fecha y la evidencia usada
  4. si no hubo revalidacion real, marcar pendiente de revalidar

Como registrar componentes

Regla practica para O7:

  • Host, Service, Container, Network, Volume, Port, Dashboard, AlertRule y Runbook deben tener ID estable
  • si el componente existe en runtime, debe tener evidencia de docker, ssh o archivo versionado
  • si el componente es futuro, debe figurar como planificado, no como activo

Como validar realidad vs documentacion

Proceso obligatorio:

  1. correr auditoria de solo lectura por ssh openclaw-vps
  2. comparar con compose versionados y catalogos
  3. actualizar O6.0-REALITY-AUDIT.md o un sucesor equivalente
  4. recien despues sincronizar catalogos o futuros exports O7

Fase 4 - Roadmap futuro

Neo4j

  • no instalar ahora
  • mantener compatibilidad por IDs y relaciones estables
  • usar solo cuando haga falta grafo operativo real y consultas avanzadas

Business Intelligence

  • reaprovechar placeholders ya versionados en Grafana
  • modelar dashboards, fuentes y ownership como entidades catalogables

Finanzas

  • preparar dominio separado para costos, facturacion, limites y conciliacion
  • no mezclarlo con infraestructura hasta que exista fuente real registrada

WooCommerce

  • usar el placeholder documental existente como destino de futuro registro
  • no crear entidades activas hasta que exista servicio real

Gestor AI Orchestrator

  • reservar un dominio propio
  • registrar agentes, pipelines, herramientas y trazas solo cuando haya runtime real y no hipotetico

Decision final de O7

  • O7 queda aprobado como foundation documental
  • O7 no queda aprobado para despliegue en srv977009
  • el siguiente hito con valor real es mantener O6 como fuente de verdad y producir exportes estructurados cuando aparezca una necesidad concreta

Evidencia clave resumida

  • VPS actual observado con 2 vCPU, 7.8 GiB RAM, 83 GB libres
  • Docker y Compose cumplen version minima oficial
  • no existe PostgreSQL actual en el VPS
  • OpenMetadata requiere PostgreSQL/MySQL y ElasticSearch/OpenSearch
  • OpenMetadata exporta metricas Prometheus y tiene conector Grafana
  • los requisitos oficiales de recursos exceden claramente el host actual