Composants · Console et outils

okadm

La CLI de déploiement : plan, install, upgrade, status, uninstall ; lab kind ou production.

Go client-go, SDK Helmopenkeel-okadm

Le module

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

Extrait de openkeel-okadm/README.md (en anglais).

Comment la compatibilité est testée

okadm ne réimplémente aucune API OpenStack : ses tests vérifient les charts et installations qu'il produit, et les clouds qu'il installe sont exercés avec de vrais clients OpenStack.

Tests unitaires et golden tests

Tests unitaires et rendu réel du chart

Plans, valeurs et étapes d'installation avec de faux clients Kubernetes et un faux releaser Helm ; le vrai chart parapluie se rend avec les valeurs d'okadm dans les deux modes.

Exécution

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

Source : openkeel-okadm/README.md

De bout en bout sur un lab

Installation sur un cluster kind neuf

Le binaire seul crée le cluster et installe les opérateurs, l'infrastructure, Keystone et Placement.

Exécution

okadm install --mode lab --components keystone,placement avec --create-kind, charts et manifestes embarqués.

Dernier résultat Tout est Ready, code de sortie 0 ; une seconde exécution recharge les images et conserve leurs tags.

Source : openkeel-okadm/README.md

De bout en bout sur un lab

Vrais clients sur un lab installé par okadm

ok et la CLI openstack Python exécutent des commandes de lecture sur chaque service installé par okadm.

Exécution

okadm install --mode lab, puis les deux CLI côte à côte.

Dernier résultat 37 / 42 commandes de lecture identiques (2026-11-02).

Source : openkeel-ok/docs/CONFORMANCE.md

Contrat client

Endpoint load balancer avec openstacksdk

L'entrée de catalogue load-balancer enregistrée par okadm fonctionne avec openstacksdk et de vrais jetons Keystone : LB en ACTIVE, listener, pool, membre, suppression en cascade.

Exécution

okadm install sur kind avec --components ovn-octavia-provider.

Dernier résultat Réussi (2026-11-01) ; pas de plan de données dans ce mode.

Source : openkeel-neutron/docs/CONFORMANCE.md

Écarté de la réécriture

okadm déploie OpenKeel sur un cluster Kubernetes existant depuis un seul binaire Go, en laissant la préparation des hôtes, le plan de données côté hôte et l'infrastructure gérée à la main à Kubernetes et à ses opérateurs.

Assuré par la plateforme Cloud Native

Préparation des hôtes par SSH et inventaire Ansible

Repris par Kubernetes

Pourquoi c'est écarté

OpenKeel cible un cluster existant (ou un cluster kind en mode lab) ; okadm plan vérifie les prérequis et affiche la commande pour chacun de ceux qui manquent.

Pourquoi la solution n'est pas affectée

Rien n'est installé sur les hôtes par SSH ; les nœuds n'ont besoin que de leurs labels de rôle Kubernetes.

Source : openkeel-okadm/README.md

Assuré par la plateforme Cloud Native

Agents libvirt et OVS sur les hôtes

Repris par KubeVirt, OVN, CSI

Pourquoi c'est écarté

Le plan de données est constitué de composants Kubernetes : KubeVirt et CDI, Kube-OVN ou OVN, et stockage CSI.

Pourquoi la solution n'est pas affectée

okadm installe ou vérifie ces composants ; VM, réseaux et volumes tournent comme des charges de travail du cluster.

Source : openkeel-okadm/README.md

Assuré par la plateforme Cloud Native

MariaDB, RabbitMQ et Memcached déployés à la main

Repris par Opérateurs Kubernetes

Pourquoi c'est écarté

Des opérateurs font tourner MariaDB Galera et RabbitMQ (pas de Memcached : aucun service Go n'en a besoin) ; okadm crée par composant les bases, utilisateurs, vhosts et Secrets générés.

Pourquoi la solution n'est pas affectée

Pas de fichier de mots de passe à maintenir ; chaque composant reçoit ses propres identifiants dans des Secrets Kubernetes.

Source : openkeel-okadm/README.md

Mécanique interne simplifiée

Chaîne d'outils Python, Ansible et helm ou kubectl

Pourquoi c'est écarté

okadm embarque client-go, le SDK Helm 3, les charts et le manifeste de release.

Pourquoi la solution n'est pas affectée

Installation, mise à niveau, état et désinstallation partent d'un seul binaire ; seules les images de conteneurs sont téléchargées.

Source : openkeel-okadm/README.md

Seul ce qui a été écarté par choix de conception figure ici ; le travail pas encore fait se trouve dans les Known gaps du docs/CONFORMANCE.md du module. Tous les modules

Aussi dans « Console et outils »

Skyline

Un seul binaire Go : API de la console, fichiers de la console React, proxy vers le catalogue Keystone.

GoConsole React amont

ok (CLI)

Le client OpenStack : commandes de python-openstackclient 10.3.1 et de ses plugins, mêmes arguments, sorties et codes retour.

GoBinaire Go statique