Componenti · Console e strumenti

okadm

La CLI di deployment: plan, install, upgrade, status, uninstall; laboratorio kind o produzione.

Go client-go, SDK Helmopenkeel-okadm

Il modulo

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

Estratto da openkeel-okadm/README.md (in inglese).

Come viene testata la compatibilità

okadm non reimplementa alcuna API OpenStack: i suoi test verificano i chart e le installazioni che produce, e i cloud che installa vengono verificati con client OpenStack reali.

Test unitari e golden test

Test unitari e rendering reale del chart

Piani, valori e passi di installazione con client Kubernetes simulati e un releaser Helm simulato; il vero chart ombrello viene renderizzato con i valori di okadm in entrambe le modalità.

Esecuzione

make test (go vet, go test -race -cover ./...), incluso TestRealChartRenders.

Fonte: openkeel-okadm/README.md

End-to-end su un laboratorio

Installazione su un nuovo cluster kind

Il solo binario crea il cluster e installa operatori, infrastruttura, Keystone e Placement.

Esecuzione

okadm install --mode lab --components keystone,placement con --create-kind, chart e manifest integrati.

Ultimo risultato Tutto Ready, codice di uscita 0; una seconda esecuzione ricarica le immagini e ne conserva i tag.

Fonte: openkeel-okadm/README.md

End-to-end su un laboratorio

Client reali su un laboratorio installato con okadm

ok e la CLI openstack Python eseguono comandi di lettura su ogni servizio installato da okadm.

Esecuzione

okadm install --mode lab, poi le due CLI affiancate.

Ultimo risultato 37 / 42 comandi di lettura identici (2026-11-02).

Fonte: openkeel-ok/docs/CONFORMANCE.md

Contratto client

Endpoint del load balancer con openstacksdk

La voce di catalogo load-balancer registrata da okadm funziona con openstacksdk e token Keystone reali: LB in ACTIVE, listener, pool, member, eliminazione a cascata.

Esecuzione

okadm install su kind con --components ovn-octavia-provider.

Ultimo risultato Superato (2026-11-01); nessun data plane in questa modalità.

Fonte: openkeel-neutron/docs/CONFORMANCE.md

Escluso dal rewrite

okadm distribuisce OpenKeel su un cluster Kubernetes esistente da un unico binario Go, lasciando a Kubernetes e ai suoi operatori la preparazione degli host, il data plane lato host e l'infrastruttura gestita a mano.

Gestito dalla piattaforma Cloud Native

Preparazione degli host via SSH e inventario Ansible

Gestito da Kubernetes

Perché è stato escluso

OpenKeel si rivolge a un cluster esistente (o a un cluster kind in modalità lab); okadm plan verifica i prerequisiti e mostra il comando per ciascuno di quelli mancanti.

Perché la soluzione non ne risente

Nulla viene installato sugli host via SSH; ai nodi servono solo le label di ruolo Kubernetes.

Fonte: openkeel-okadm/README.md

Gestito dalla piattaforma Cloud Native

Agenti libvirt e OVS sugli host

Gestito da KubeVirt, OVN, CSI

Perché è stato escluso

Il data plane è composto da componenti Kubernetes: KubeVirt e CDI, Kube-OVN o OVN, e storage CSI.

Perché la soluzione non ne risente

okadm installa o verifica questi componenti; VM, reti e volumi girano come carichi di lavoro del cluster.

Fonte: openkeel-okadm/README.md

Gestito dalla piattaforma Cloud Native

MariaDB, RabbitMQ e Memcached distribuiti a mano

Gestito da Operatori Kubernetes

Perché è stato escluso

Degli operatori eseguono MariaDB Galera e RabbitMQ (niente Memcached: nessun servizio Go ne ha bisogno); okadm crea per componente database, utenti, vhost e Secret generati.

Perché la soluzione non ne risente

Nessun file di password da mantenere; ogni componente riceve le proprie credenziali in Secret Kubernetes.

Fonte: openkeel-okadm/README.md

Meccanismi interni semplificati

Toolchain Python, Ansible e helm o kubectl

Perché è stato escluso

okadm incorpora client-go, l'SDK di Helm 3, i chart e il manifest di release.

Perché la soluzione non ne risente

Installazione, aggiornamento, stato e disinstallazione partono da un unico binario; vengono scaricate solo le immagini dei container.

Fonte: openkeel-okadm/README.md

Qui è elencato solo ciò che è stato escluso per scelta progettuale; il lavoro non ancora svolto si trova nei Known gaps del docs/CONFORMANCE.md del modulo. Tutti i moduli

Anche in Console e strumenti

Skyline

Un unico binario Go: l'API della console, i file della console React e un proxy verso il catalogo Keystone.

GoConsole React upstream

ok (CLI)

Il client OpenStack: i comandi di python-openstackclient 10.3.1 e dei suoi plugin, con gli stessi argomenti, output e codici di uscita.

GoBinario Go statico