The project

Improvements

Beyond iso-functionality: tooling, security and ease of use.

Go: the Cloud Native language

The Cloud Native language

Kubernetes, etcd, containerd, Helm, Prometheus, KubeVirt: the same language as the platform

Integrated ecosystem

client-go, Helm SDK, OVSDB, Prometheus, OIDC: native libraries, no bridges

Typed and compiled

Strong typing, errors caught at compile time, faster code than Python

Fast builds

One static binary per service, fast compilation, multi-architecture

Minimal containers

One executable, rootless, no shell or sources, on distroless rather than Ubuntu

Lean at run time

No interpreter and no eventlet (start-up time and memory not measured in the workspace)

Tooling: script, deploy, steer

Three tools that OpenStack does not have in this form, written in Go like the services and shipped with every OpenKeel release.

The OpenStack CLI, in Go

ok is the openstack command rewritten in Go: one static binary, with no Python, virtualenv or plugins to install.

All 1,325 commands of python-openstackclient 10.3.1 and its plugins, each checked against the Python CLI by differential replay
Same arguments, output formats, error messages and exit codes: existing scripts keep working
Reads clouds.yaml, OS_* and --os-* like the original; Linux, macOS and Windows binaries, and a distroless image

export OS_CLOUD=openkeel
ok server list -f json

Learn more

okadm

Plug-and-play deployment, lab or production

okadm installs OpenKeel on a Kubernetes cluster with one command per step of the life cycle, in lab or production mode.

Lab: with no cluster, it creates a kind cluster, installs the lab operators and one replica of each service; --ingress adds the public entry point
Production: okadm plan checks the prerequisites (version, node roles, operators, StorageClass, domain) and prints the fix for each; three replicas
Idempotent install that resumes where it stopped, component-by-component upgrade, status, uninstall; client-go and the Helm SDK built in

okadm plan --mode production
okadm install --mode lab \
  --create-kind --ingress --demo

Learn more

Configurator

Steer the deployment graphically

The Configurator is a web console, installed by default by okadm, to prepare a deployment of the OpenKeel modules and follow it visually.

Node roles (control plane, compute, network, storage, containers, provisioning) and the placement of each component, by drag and drop in a topology view by availability zone
Parameters of each service: enabled, replicas, autoscaling, resources, free YAML; checks of quorum, anti-affinity and role minimums
Visual follow-up: the distribution of components on the nodes, the state of the pods (ready, restarts) and the logs of every service, merged and searchable
Produces the values of okadm install -f and the node labels, or labels the nodes itself

Watch the tour

Less code, the same guarantees

1,008 kPython lines in the 19 original modules
310 kGo lines in the OpenKeel modules
−69%code, tests excluded

Module	Python	Go	Change
Placement	10,287	10,256	0%
Nova	150,846	20,534	−86%
Zun	30,938	13,947	−55%
Masakari	10,835	9,347	−14%
Cinder	255,934	17,400	−93%
Glance	31,279	14,372	−54%
Manila	135,162	18,285	−86%
Neutron	127,623	25,947	−80%
Octavia (OVN)	5,778	9,042	+56%
Neutron-FWaaS	8,085	9,643	+19%
Neutron-VPNaaS	6,449	11,190	+74%
OVN-BGP-Agent	8,448	5,074	−40%
Keystone	50,584	21,015	−58%
Barbican	18,688	12,851	−31%
Designate	23,671	15,367	−35%
CloudKitty	15,020	12,042	−20%
EC2 API	11,570	16,272	+41%
Skyline	18,723	8,590	−54%
ok (CLI)	88,122	59,156	−33%
Total	1,008,042	310,330	−69%

Non-blank, non-comment lines, tests excluded, counted when the site is generated. On the Python side only the service package is counted: oslo, neutron-lib, keystonemiddleware and os-brick are not, while their equivalents live inside each Go module. Drivers and agents replaced by Kubernetes disappear; small modules once grafted onto Neutron or Nova grow, because they become standalone services.

Configuration: from oslo.config to YAML

	OpenStack (Python)	OpenKeel (Go)
Files	oslo.config INI, plus api-paste.ini, rootwrap.conf and its filters, logging.conf, policy	One config.yaml per process, mounted from a ConfigMap
Secrets	Passwords inside connection and transport_url	*_file fields read from mounted Secrets, never in the YAML
Process	bind_host, workers, log_file, use_syslog, debug	Handled by Kubernetes; a single default.log_level
Drivers	Options of every shipped driver (libvirt, VMware, arrays, ML2…)	Only the options of the chosen building blocks (KubeVirt, CSI, OVN)
Validation	A separate check with the oslo-config-validator tool	Strict decoding: an unknown key or an out-of-range value, and the process refuses to start
Change	Edit the files on each host, restart	New ConfigMap hash, rolling restart; log level through SIGHUP

Same names: groups, options and defaults of the original; OPENKEEL_<GROUP>_<OPTION> overrides a value for one pod.

Fewer options: keep only what matters

Module	Kept	Dropped
Placement	7	101
Nova	122	1,015
Zun	63	300
Masakari	35	235
Cinder	49	1,411
Glance	66	472
Manila	82	905
Neutron	82	443
Keystone	100	313
Barbican	72	200
Designate	84	300
CloudKitty	50	271
EC2 API	16	151

828options kept out of 6,945, in 13 modules
88%of the oslo options dropped

Counts read from each module's config/dropped-options.md; every dropped option is listed there with its reason. Dropped: deprecated options, drivers not shipped, eventlet and file locks, process options taken over by Kubernetes. Kept: everything that changes the API, the data or the limits (quotas, allocation ratios, token lifetime, enforce_scope).

Security and ease of use

Skyline-OIDC

Console login through an OIDC identity provider: federation, SSO, tokens validated with JWKS.

Rotating internal secrets

Database passwords, RabbitMQ accounts and service keys managed as rotating components, renewable without manual work.

EC2 credentials in Skyline

Create and manage EC2 credentials (access / secret) from the console, to reach S3 storage.