La CLI de despliegue: plan, install, upgrade, status, uninstall; laboratorio kind o producción.
Go client-go, SDK de Helmopenkeel-okadm
El módulo
okadm checks, installs and upgrades OpenKeel on an existing Kubernetes cluster, with one command per lifecycle step:
okadm plan --mode lab # does the cluster meet the prerequisites? what is missing, how to fix it
okadm install --mode lab # no cluster configured: offers to create a kind cluster
okadm upgrade --version 2026.2.1 # one component at a time, in dependency order
okadm install --mode lab --create-kind --ingress # kind with 127.0.0.1:80/443 forwarded, Traefik, the console at http://skyline.127.0.0.1.nip.io
okadm status # installed version, Helm releases, state of their pods
okadm uninstall --yes # components, then data services; volumes kept unless --purge
okadm install --component csi-tester --pure-endpoint fa.example.org --pure-api-token-file ./api-token
# only the FlashArray CSI driver and its test application
Go module: github.com/openkeel/openkeel-okadm, binary okadm (cmd/okadm)
Built on cobra, k8s.io/cli-runtime (kubectl connection flags), client-go and the Helm 3 Go SDK; no kubectl or helm binary is needed
The release manifest (which component version makes up each OpenKeel version) is embedded: internal/manifest/releases.yaml
Extracto de openkeel-okadm/README.md (en inglés).
Cómo se prueba la compatibilidad
okadm no reimplementa ninguna API de OpenStack: sus tests verifican los charts e instalaciones que produce, y las nubes que instala se ejercitan con clientes OpenStack reales.
Tests unitarios y golden tests
Tests unitarios y renderizado real del chart
Planes, valores y pasos de instalación con clientes Kubernetes simulados y un releaser de Helm simulado; el chart paraguas real se renderiza con los valores de okadm en ambos modos.
Ejecución
make test (go vet, go test -race -cover ./...), incluido TestRealChartRenders.
Fuente: openkeel-okadm/README.md
De extremo a extremo en un laboratorio
Instalación en un clúster kind nuevo
El binario por sí solo crea el clúster e instala los operadores, la infraestructura, Keystone y Placement.
Ejecución
okadm install --mode lab --components keystone,placement con --create-kind, charts y manifiestos integrados.
Último resultado Todo en Ready, código de salida 0; una segunda ejecución recarga las imágenes y conserva sus etiquetas.
Fuente: openkeel-okadm/README.md
De extremo a extremo en un laboratorio
Clientes reales en un laboratorio instalado con okadm
ok y la CLI openstack de Python ejecutan comandos de lectura sobre cada servicio instalado por okadm.
Ejecución
okadm install --mode lab, y luego ambas CLI en paralelo.
Último resultado 37 / 42 comandos de lectura idénticos (2026-11-02).
Fuente: openkeel-ok/docs/CONFORMANCE.md
Contrato de cliente
Endpoint de load balancer con openstacksdk
La entrada de catálogo load-balancer que registra okadm funciona con openstacksdk y tokens reales de Keystone: LB en ACTIVE, listener, pool, miembro, eliminación en cascada.
Ejecución
okadm install en kind con --components ovn-octavia-provider.
Último resultado Superado (2026-11-01); sin plano de datos en este modo.
Fuente: openkeel-neutron/docs/CONFORMANCE.md
Excluido del rewrite
okadm despliega OpenKeel en un clúster de Kubernetes existente desde un único binario Go, y deja la preparación de los hosts, el plano de datos del lado del host y la infraestructura gestionada a mano a Kubernetes y sus operadores.
Asumido por la plataforma Cloud Native
Preparación de hosts por SSH e inventario de Ansible
Asumido por Kubernetes
Por qué se excluyó
OpenKeel se dirige a un clúster existente (o a un clúster kind en modo laboratorio); okadm plan comprueba los requisitos previos y muestra el comando para cada uno que falte.
Por qué la solución no se ve afectada
No se instala nada en los hosts por SSH; los nodos solo necesitan sus etiquetas de rol de Kubernetes.
Fuente: openkeel-okadm/README.md
Asumido por la plataforma Cloud Native
Agentes libvirt y OVS en los hosts
Asumido por KubeVirt, OVN, CSI
Por qué se excluyó
El plano de datos está formado por componentes de Kubernetes: KubeVirt y CDI, Kube-OVN u OVN, y almacenamiento CSI.
Por qué la solución no se ve afectada
okadm instala o comprueba estos componentes; VM, redes y volúmenes se ejecutan como cargas de trabajo del clúster.
Fuente: openkeel-okadm/README.md
Asumido por la plataforma Cloud Native
MariaDB, RabbitMQ y Memcached desplegados a mano
Asumido por Operadores de Kubernetes
Por qué se excluyó
Unos operadores ejecutan MariaDB Galera y RabbitMQ (sin Memcached: ningún servicio Go lo necesita); okadm crea por componente las bases de datos, usuarios, vhosts y Secrets generados.
Por qué la solución no se ve afectada
Ningún archivo de contraseñas que mantener; cada componente recibe sus propias credenciales en Secrets de Kubernetes.
Fuente: openkeel-okadm/README.md
Mecánica interna simplificada
Cadena de herramientas Python, Ansible y helm o kubectl
Por qué se excluyó
okadm integra client-go, el SDK de Helm 3, los charts y el manifiesto de release.
Por qué la solución no se ve afectada
Instalación, actualización, estado y desinstalación se ejecutan desde un solo binario; solo se descargan imágenes de contenedor.
Fuente: openkeel-okadm/README.md
Aquí solo figura lo que se excluyó por diseño; el trabajo aún no realizado está en los Known gaps del docs/CONFORMANCE.md del módulo. Todos los módulos