Components · Console and tools

okadm

The deployment CLI: plan, install, upgrade, status, uninstall; kind lab or production.

Go client-go, Helm SDKopenkeel-okadm

The 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

Excerpt from openkeel-okadm/README.md (in English).

How compatibility is tested

okadm reimplements no OpenStack API: its tests check the charts and installs it produces, and the clouds it installs are exercised with real OpenStack clients.

Unit and golden tests

Unit tests and real chart rendering

Plans, values and install steps with fake Kubernetes clients and a fake Helm releaser; the real umbrella chart renders with okadm's values in both modes.

How it runs

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

Source: openkeel-okadm/README.md

End to end on a lab

Install on a fresh kind cluster

The binary alone creates the cluster and installs operators, infrastructure, Keystone and Placement.

How it runs

okadm install --mode lab --components keystone,placement with --create-kind, embedded charts and manifests.

Latest result All Ready, exit 0; a second run reloads the images and keeps their tags.

Source: openkeel-okadm/README.md

End to end on a lab

Real clients on an okadm-installed lab

ok and the Python openstack CLI run read commands over every service installed by okadm.

How it runs

okadm install --mode lab, then both CLIs side by side.

Latest result 37 / 42 read commands identical (2026-11-02).

Source: openkeel-ok/docs/CONFORMANCE.md

Client contract

Load balancer endpoint with openstacksdk

The load-balancer catalog entry okadm registers works with openstacksdk and real Keystone tokens: LB to ACTIVE, listener, pool, member, cascade delete.

How it runs

okadm install on kind with --components ovn-octavia-provider.

Latest result Pass (2026-11-01); no data plane in this mode.

Source: openkeel-neutron/docs/CONFORMANCE.md

Left out of the rewrite

okadm deploys OpenKeel on an existing Kubernetes cluster from one Go binary, leaving host preparation, host-side data plane and hand-managed infrastructure to Kubernetes and its operators.

Done by the Cloud Native platform

SSH host preparation and Ansible inventory

Taken over by Kubernetes

Why it was left out

OpenKeel targets an existing cluster (or a kind cluster in lab mode); okadm plan checks prerequisites and prints the command for each missing one.

Why the solution is not affected

Nothing is installed on hosts by SSH; nodes only need their Kubernetes role labels.

Source: openkeel-okadm/README.md

Done by the Cloud Native platform

libvirt and OVS agents on hosts

Taken over by KubeVirt, OVN, CSI

Why it was left out

The data plane is made of Kubernetes components: KubeVirt and CDI, Kube-OVN or OVN, and CSI storage.

Why the solution is not affected

okadm installs or checks these components; VMs, networks and volumes run as cluster workloads.

Source: openkeel-okadm/README.md

Done by the Cloud Native platform

Hand-deployed MariaDB, RabbitMQ and Memcached

Taken over by Kubernetes operators

Why it was left out

Operators run MariaDB Galera and RabbitMQ (no Memcached: no Go service needs it); okadm creates per-component databases, users, vhosts and generated Secrets.

Why the solution is not affected

No password file to maintain; each component gets its own credentials in Kubernetes Secrets.

Source: openkeel-okadm/README.md

Internal machinery simplified

Python, Ansible and helm or kubectl toolchain

Why it was left out

okadm embeds client-go, the Helm 3 SDK, the charts and the release manifest.

Why the solution is not affected

Install, upgrade, status and uninstall run from one binary; only container images are fetched.

Source: openkeel-okadm/README.md

Only what was left out by design is listed here; the work not done yet is in the Known gaps of the module's docs/CONFORMANCE.md. Every module

Also in Console and tools

Skyline

A single Go binary: the console API, the React console files, and a proxy to the Keystone catalog.

GoUpstream React console

ok (CLI)

The OpenStack client: the commands of python-openstackclient 10.3.1 and its plugins, with the same arguments, outputs and exit codes.

GoStatic Go binary