OpenKeel: the sovereign French Cloud solution of the inherent group, with a European reach Discover inherent
Components · Compute and capacity
Resource inventories and allocations; the first component rewritten in Go.
OpenKeel implementation in Go of OpenStack placement (placement-api), generated from the reverse-specification of branch stable/2026.2 by the generate-go-from-spec skill. It replaces the Python service without its clients noticing: same routes, status codes, error bodies, microversions and policies. What is reproduced and what differs is in docs/CONFORMANCE.md; the security checklist is in docs/SECURITY.md.
github.com/openkeel/openkeel-placementplacement-api (API on port 8778, health and metrics on 9090)Excerpt from openkeel-placement/README.md (in English).
37 operations of the original REST API (routes and body actions), and their state in OpenKeel.
The recorded gabbi exchanges of Python Placement are replayed against the Go service, and Nova's own functional suite runs with the Go service in place of Python Placement.
Every request of the 79 upstream gabbi files gives the same status and body as the recorded Python service.
make e2e, with E2E_MYSQL_DSN for MariaDB; report in test/e2e/report.json, differences listed in known-differences.txt.
Latest result 1303 / 1316 identical on MariaDB 11.4 (1301 / 1316 on go-mysql-server); none of the remaining differences is a functional bug.
Source: openkeel-placement/docs/CONFORMANCE.md
The allocation-candidates algorithm returns the same candidates as Python on 83 recorded cases, up to 6000 providers.
go test -tags e2e -run TestAllocationCandidateCases ./test/e2e/; report in test/e2e/cases-report.json.
Latest result 81 / 83 identical, 83 / 83 on the number of candidates.
Source: openkeel-placement/docs/CONFORMANCE.md
Nova's functional test suite passes when every Placement call is served by the Go service instead of Python Placement.
Nova's functional tests run through test/nova-functional/run.sh, on go-mysql-server and MariaDB 11.4, compared with a Python Placement baseline.
Latest result Subset 859 / 859 on MariaDB 11.4 (as Python); full suite 3314 passed, 1 failed (an engine bug) on go-mysql-server (2026-10-28).
Source: openkeel-placement/docs/NOVA-FUNCTIONAL.md
Concurrent allocations through three service instances on three Galera nodes never overallocate a resource provider.
GALERA_DSNS=... go test -tags galera ./test/galera/ on a 3-node MariaDB Galera 11.4 cluster.
Latest result Pass: 180 concurrent allocations for 100 VCPU give exactly 100 allocations, 0 unexpected status.
Source: openkeel-placement/docs/CONFORMANCE.md
Tempest and Nova functional tests against a deployed Placement on a cluster.
Needs a kind cluster (reverse-spec 07 § 7 step 5).
Latest result Not run.
Source: openkeel-placement/docs/CONFORMANCE.md
Placement keeps its whole API and leaves out only the unauthenticated test mode, legacy data migrations and the oslo service plumbing that Kubernetes already provides.
An API without authentication has no place in production; the test suites inject a token validator instead.
Clients always authenticate through Keystone, as they do in any real deployment. Nova, Neutron and osc-placement are unaffected.
Source: openkeel-placement/docs/CONFORMANCE.md
set_root_provider_ids and create_incomplete_consumers only fix databases older than the reproduced branch.
A fresh or current database never needs them; databases older than the branch are refused instead of being migrated in place.
Source: openkeel-placement/docs/CONFORMANCE.md
Taken over by Ingress (Gateway API)
Cross-origin headers are a concern of the HTTP edge, not of each API process.
No OpenKeel client calls Placement from a browser on another origin; where needed, CORS is configured once on the ingress.
Source: openkeel-placement/docs/CONFORMANCE.md
Taken over by Kubernetes probes, OpenTelemetry
Logs go to stdout as JSON, traces to OpenTelemetry and health to Kubernetes probes; 101 of 108 oslo options became useless.
Operators get the same information through the cluster's log, tracing and probe tooling; the API is unchanged.
Source: openkeel-placement/config/dropped-options.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
Service view generated by the diagram skill from the OpenKeel model.
Full screen| From | To | Protocol | What |
|---|---|---|---|
| Nova API | Placement | REST API | usages, quotas |
| Nova conductor + scheduler | Placement | REST API | allocation candidates, claims |
| Nova compute agent | Placement | REST API | inventory, traits |
| Zun API | Placement | REST API | allocation candidates, claims |
| Zun compute agent | Placement | REST API | inventory (Node UID provider) |
Branch stable-2026.2 · 9 files
Read the reverse-specBranch stable-2026.2 · 9 files
Read the reverse-specInstances run as KubeVirt VirtualMachines; conductor with the scheduler in process, one agent per node.
Containers as a Service: one Pod per container, isolated in its own Kata microVM, with its Neutron port as its only network.
Instance high availability; node health from Node Healthcheck and Self Node Remediation.
Bare metal: stays upstream Python, packaged in an OpenKeel chart; too many hardware configurations to test.