OpenKeel: die souveräne französische Cloud-Lösung mit europäischer Reichweite der inherent-Gruppe inherent entdecken
Komponenten · Compute und Kapazität
Ressourceninventare und Allokationen; die erste in Go neu geschriebene Komponente.
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)Auszug aus openkeel-placement/README.md (auf Englisch).
37 Operationen der Original-REST-API (Routen und Body-Aktionen) und ihr Status in OpenKeel.
Die aufgezeichneten gabbi-Austausche von Python-Placement werden gegen den Go-Dienst wiedergegeben, und Novas eigene Funktionstest-Suite läuft mit dem Go-Dienst anstelle von Python-Placement.
Jede Anfrage der 79 Upstream-gabbi-Dateien liefert denselben Status und Body wie der aufgezeichnete Python-Dienst.
make e2e, mit E2E_MYSQL_DSN für MariaDB; Bericht in test/e2e/report.json, Unterschiede aufgeführt in known-differences.txt.
Letztes Ergebnis 1303 / 1316 identisch auf MariaDB 11.4 (1301 / 1316 auf go-mysql-server); keiner der verbleibenden Unterschiede ist ein funktionaler Fehler.
Quelle: openkeel-placement/docs/CONFORMANCE.md
Der allocation-candidates-Algorithmus liefert bei 83 aufgezeichneten Fällen mit bis zu 6000 Providern dieselben Kandidaten wie Python.
go test -tags e2e -run TestAllocationCandidateCases ./test/e2e/; Bericht in test/e2e/cases-report.json.
Letztes Ergebnis 81 / 83 identisch, 83 / 83 bei der Anzahl der Kandidaten.
Quelle: openkeel-placement/docs/CONFORMANCE.md
Die Funktionstest-Suite von Nova besteht, wenn jeder Placement-Aufruf vom Go-Dienst statt von Python-Placement bedient wird.
Die Nova-Funktionstests laufen über test/nova-functional/run.sh, auf go-mysql-server und MariaDB 11.4, verglichen mit einer Python-Placement-Referenz.
Letztes Ergebnis Teilmenge 859 / 859 auf MariaDB 11.4 (wie Python); vollständige Suite 3314 bestanden, 1 fehlgeschlagen (ein Engine-Fehler) auf go-mysql-server (2026-10-28).
Quelle: openkeel-placement/docs/NOVA-FUNCTIONAL.md
Nebenläufige Allokationen über drei Dienstinstanzen auf drei Galera-Knoten überbuchen nie einen Resource Provider.
GALERA_DSNS=... go test -tags galera ./test/galera/ auf einem MariaDB-Galera-11.4-Cluster mit 3 Knoten.
Letztes Ergebnis Bestanden: 180 nebenläufige Allokationen für 100 VCPU ergeben genau 100 Allokationen, 0 unerwartete Status.
Quelle: openkeel-placement/docs/CONFORMANCE.md
Tempest- und Nova-Funktionstests gegen ein auf einem Cluster bereitgestelltes Placement.
Erfordert einen kind-Cluster (reverse-spec 07 § 7 Schritt 5).
Letztes Ergebnis Nicht ausgeführt.
Quelle: openkeel-placement/docs/CONFORMANCE.md
Placement behält seine gesamte API und verzichtet nur auf den nicht authentifizierten Testmodus, alte Datenmigrationen und die oslo-Service-Infrastruktur, die Kubernetes bereits bereitstellt.
Eine API ohne Authentifizierung hat in der Produktion keinen Platz; die Testsuiten injizieren stattdessen einen Token-Validator.
Clients authentifizieren sich immer über Keystone, wie in jedem realen Deployment. Nova, Neutron und osc-placement sind nicht betroffen.
Quelle: openkeel-placement/docs/CONFORMANCE.md
set_root_provider_ids und create_incomplete_consumers korrigieren nur Datenbanken, die älter als der nachgebildete Branch sind.
Eine neue oder aktuelle Datenbank benötigt sie nie; Datenbanken, die älter als der Branch sind, werden abgewiesen, statt vor Ort migriert zu werden.
Quelle: openkeel-placement/docs/CONFORMANCE.md
Übernommen von Ingress (Gateway API)
Cross-Origin-Header sind Sache des HTTP-Edge, nicht jedes einzelnen API-Prozesses.
Kein OpenKeel-Client ruft Placement aus einem Browser auf einer anderen Origin auf; wo nötig, wird CORS einmal am Ingress konfiguriert.
Quelle: openkeel-placement/docs/CONFORMANCE.md
Übernommen von Kubernetes probes, OpenTelemetry
Logs gehen als JSON auf stdout, Traces an OpenTelemetry und der Zustand an Kubernetes-Probes; 101 von 108 oslo-Optionen wurden überflüssig.
Betreiber erhalten dieselben Informationen über die Log-, Tracing- und Probe-Werkzeuge des Clusters; die API bleibt unverändert.
Quelle: openkeel-placement/config/dropped-options.md
Hier ist nur aufgeführt, was bewusst ausgelassen wurde; noch nicht erledigte Arbeit steht in den Known gaps der docs/CONFORMANCE.md des Moduls. Alle Module
Dienstansicht, vom Diagramm-Skill aus dem OpenKeel-Modell generiert.
Vollbild| Von | Nach | Protokoll | Was |
|---|---|---|---|
| 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 Dateien
Reverse-Spec lesenBranch stable-2026.2 · 9 Dateien
Reverse-Spec lesenInstanzen laufen als KubeVirt-VirtualMachines; Conductor mit integriertem Scheduler, ein Agent pro Knoten.
Containers as a Service: ein Pod pro Container, isoliert in einer eigenen Kata-MicroVM, mit seinem Neutron-Port als einzigem Netz.
Hochverfügbarkeit von Instanzen; Knotenzustand über Node Healthcheck und Self Node Remediation.
Bare Metal: bleibt upstream Python, verpackt in einem OpenKeel-Chart; zu viele Hardwarekonfigurationen zum Testen.