OpenKeel: the sovereign French Cloud solution of the inherent group, with a European reach Discover inherent
Components · Compute and capacity
Instance high availability; node health from Node Healthcheck and Self Node Remediation.
OpenKeel implementation in Go of OpenStack Masakari, the instance high-availability service (masakari-api, masakari-engine, masakari-manage), 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-masakarimasakari-api: the instance-ha API v1, microversions 1.0–1.3 (port 15868; health and metrics on 9090);masakari-engine: claims new notifications and runs the recovery workflows (host evacuation by segment recovery method, instance restart, compute-service disable) through Nova (openkeel-nova), runs the periodic tasks on the Lease holder and, in a cluster, the Medik8s/KubeVirt integration below;masakari-manage: db sync, db version, db purge.internal/kube, [references/backends/masakari-kubevirt.md] of the skill and openkeel-docs/NODE-PLACEMENT.md § 5.6 of the workspace): one Medik8s NodeHealthCheck per segment detects and fences failed nodes (Self Node Remediation, OutOfServiceTaint); the engine reports the host failure only once the node is fenced and evacuates its VMs per segment policy; it live-migrates the VMs of degraded or drained nodes before they fail, and mirrors segments and reserved hosts on node labels and taints.Excerpt from openkeel-masakari/README.md (in English).
21 operations of the original REST API (routes and body actions), and their state in OpenKeel.
Python Masakari's recorded scenarios are replayed against the Go service, the recovery engine is compared with the Nova calls Python made, and concurrency is tested on Galera.
The 201 exchanges of 23 ordered scenarios, with the same fake Nova and periodic tasks, give the same answers as Python.
make e2e, on go-mysql-server and on MariaDB 11.4 (E2E_MYSQL_DSN); make e2e-strict passes.
Latest result 195 / 201 on both engines; 6 deliberate differences listed in test/e2e/known-differences.txt.
Source: openkeel-masakari/docs/CONFORMANCE.md
Host and instance recovery flows send Nova the same mutations, per server, service and aggregate, as the Python engine.
internal/engine/engine_test.go on nova-calls_stable-2026.2.json (143 requests).
Latest result Identical mutations per server, service and aggregate; GET polling counts are not compared.
Source: openkeel-masakari/docs/CONFORMANCE.md
API routing, microversions, validation messages and the 24 policy rules for two personas behave as in Python.
make test, with client-go fakes for the Kubernetes integration.
Latest result Pass.
Source: openkeel-masakari/docs/CONFORMANCE.md
Unique names and duplicate notifications hold through three nodes, and engines on three nodes evacuate a host only once.
make galera-test on a 3-node cluster.
Latest result Pass: same-name segments and hosts 1 × 201, 17 × 409; duplicate notifications 1 × 202, 23 × 409.
Source: openkeel-masakari/docs/CONFORMANCE.md
Masakari functional tests (openstacksdk) and Tempest-like tests against a deployed service.
Need a deployed cluster.
Latest result Not run.
Source: openkeel-masakari/docs/CONFORMANCE.md
Masakari keeps its API and recovery workflows but detects host failures with Medik8s instead of masakari-monitors and replaces RPC, taskflow and tooz with database claims.
Taken over by Medik8s
Kubernetes already detects unhealthy nodes: one NodeHealthCheck per segment, with Self Node Remediation or Fence Agents Remediation, fences the node.
The engine raises the same COMPUTE_HOST notification once the node is fenced, so evacuation works as before. The instance and process monitors are not replaced yet.
Source: openkeel-masakari/docs/CONFORMANCE.md
Taken over by Kubernetes Leases
The API inserts the notification row and engine replicas claim it with a compare-and-swap; duplicates and per-host work are serialised by database rows that work across Galera nodes.
No RabbitMQ is needed and no cast can be lost; the Galera test gives exactly one 202 for 24 identical concurrent reports.
Source: openkeel-masakari/docs/CONFORMANCE.md
Progress is a table of the single database instead of a second taskflow database; Go has no plugin loading, so the default flow lists are built in.
recovery_workflow_details returns the same progress list. Custom task lists and third-party stevedore tasks are not supported.
Source: openkeel-masakari/docs/CONFORMANCE.md
Taken over by Kubernetes probes
A Go HTTP server replaces the WSGI stack, Kubernetes manages processes and probes, and the osapi_v1 options are deprecated upstream.
The API and its microversions 1.0 to 1.3 are unchanged.
Source: openkeel-masakari/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 |
|---|---|---|---|
| Masakari engine + monitors | Nova API | REST API | server state, host disable |
| Masakari API | Masakari engine + monitors | RabbitMQ | RPC notification |
| Masakari engine + monitors | Medik8s NHC + SNR | Kubernetes API | NodeHealthCheck, remediation status |
| Masakari engine + monitors | KubeVirt | Kubernetes API | VMI delete, live migration |
Branch stable-2026.2 · 8 files
Read the reverse-specResource inventories and allocations; the first component rewritten in Go.
Instances 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.
Bare metal: stays upstream Python, packaged in an OpenKeel chart; too many hardware configurations to test.