Instanzen laufen als KubeVirt-VirtualMachines; Conductor mit integriertem Scheduler, ein Agent pro Knoten.
Go KubeVirt und CDIopenkeel-nova
Das Modul
OpenKeel implementation in Go of OpenStack nova (the compute API, its conductor with the scheduler in process, and a per-node compute agent), with KubeVirt as hypervisor and Ironic for bare-metal flavors, 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.
Go module: github.com/openkeel/openkeel-nova
Binaries (one image): nova-api (API on port 8774, health and metrics on 9090), nova-conductor (consumes the conductor queue on RabbitMQ, schedules through Placement, drives KubeVirt and Ironic), nova-compute-agent (DaemonSet on compute nodes: service record, heartbeat, hypervisor row, Placement inventory), nova-ironic-agent (Deployment, one replica active behind a Lease: the same for each Ironic node, rendered when peers.ironic_endpoint is set), nova-console-proxy (Deployment, consoleProxy.enabled: noVNC and console websockets on port 6080, see Consoles below)
Backends: the skill reference nova-kubevirt.md (flavor → instancetype/preference, VirtualMachine per server in os-<project>), bare-metal flavors (resources:CUSTOM_BAREMETAL_*=1) to openkeel-ironic, node placement per openkeel-docs/NODE-PLACEMENT.md of the workspace
Configuration: YAML, see config/config.example.yaml
Setting up a development environment, the database and the tests: docs/GETTING-STARTED.md
Database schema, migrations and upgrades: docs/DATABASE.md
Auszug aus openkeel-nova/README.md (auf Englisch).
REST-API
273 Operationen der Original-REST-API (Routen und Body-Aktionen) und ihr Status in OpenKeel.
Die API-Beispiel-Austausche von Python-Nova werden gegen den Go-Dienst wiedergegeben, die Nebenläufigkeit wird auf Galera getestet, und echte KubeVirt-Gäste werden im Lab gestartet und per Drain verschoben.
Replay aufgezeichneter Austausche
E2E-Replay der API-Beispiele
Jeder aufgezeichnete API-Beispiel-Austausch von Python-Nova liefert vom Go-Dienst denselben Status und Body, mit einer frischen Datenbank pro Datei.
Ausführung
make e2e (1233 Dateien), auf go-mysql-server und auf MariaDB 11.4 mit E2E_MYSQL_DSN; Bericht in test/e2e/report.json.
Letztes Ergebnis 1957 / 2590 identisch auf beiden Engines; die verbleibenden Unterschiede sind vor allem nicht implementierte APIs (501) und Tests, die die Datenbank durch Stubs ersetzen.
Quelle: openkeel-nova/docs/CONFORMANCE.md
Unit- und Golden Tests
Unit-, Policy- und Flavor-Vektoren
Router-Pipeline, Validierungsmeldungen, die 214 Policy-Regeln, Zustandstabelle, Scheduler-Ressourcen und die Umwandlung von Flavors in KubeVirt verhalten sich wie spezifiziert.
Ausführung
make test; Flavor-Vektoren in internal/driver/kubevirt/flavor_test.go.
Kontingente, eindeutige Namen und nebenläufige Aktionen halten, wenn Anfragen gleichzeitig über drei Galera-Knoten eintreffen.
Ausführung
test/galera auf einem Cluster mit 3 Knoten: nebenläufige Starts, Schlüsselpaare, Servergruppen, Erstellungen mit gleichem Namen und Stopps.
Letztes Ergebnis Bestanden, 3 von 3 Durchläufen: genau 10 Server für ein Kontingent von 10 bei 30 Starts, kein 5xx.
Quelle: openkeel-nova/docs/CONFORMANCE.md
End-to-End in einem Lab
VM-NICs an Neutron-Ports, echte Gäste
POST /servers mit Neutron-Ports startet echte Gäste, die ihre Neutron-Adressen erhalten, zwischen Projekten isoliert sind und eine Live-Migration überstehen.
Letztes Ergebnis Bestanden (2026-10-31); die Live-Migration über den Conductor auf einer local-path-Festplatte wird von KubeVirt abgelehnt und nur durch Unit-Tests abgedeckt.
Quelle: openkeel-nova/docs/CONFORMANCE.md
Szenario
kubectl drain eines Compute-Knotens
Ein Drain migriert den Gast live, und Nova übernimmt die Migration: Host, Port-Binding, OVN-Chassis und Placement-Allokation folgen.
Ausführung
openkeel-lab/scripts/drain-test.sh im dataplane-Lab, mit zwei über POST /servers erstellten Servern.
Letztes Ergebnis Bestanden (2026-10-31); ein Peer verlor 1 von 55 Pings. Keine gemeinsame Festplatte migriert, kein Knoten vollständig geleert.
Quelle: openkeel-nova/docs/CONFORMANCE.md
Tempest
Tempest compute
Die Upstream-Tempest-Compute-API-Tests gegen ein bereitgestelltes Nova.
Ausführung
Erfordert einen kind-Cluster mit KubeVirt, CDI, Longhorn und den übrigen OpenKeel-Diensten.
Letztes Ergebnis Nicht ausgeführt.
Quelle: openkeel-nova/docs/CONFORMANCE.md
Im Rewrite ausgelassen
Nova behält seine API und sein Scheduling-Modell, überlässt den Hypervisor aber KubeVirt; damit entfallen Zellen, nova-compute-Dienste pro Host und die veralteten Proxy-APIs.
Vereinfachte interne Mechanik
Cells v2, cell0 und build requests
Warum es ausgelassen wurde
Ein Kubernetes-natives Deployment betreibt eine einzige Zelle: Ein Schema enthält die Tabellen von nova_api und der Zellendatenbank, und die Instanzzeile wird in einem Schritt geschrieben.
Warum die Lösung nicht beeinträchtigt ist
In der API sichtbare Konzepte (instance mappings, request specs, BUILD- und ERROR-Zustände mit faults) bleiben erhalten, sodass Clients denselben Server-Lebenszyklus sehen.
Quelle: openkeel-nova/docs/CONFORMANCE.md
Von der Cloud-Native-Plattform übernommen
nova-compute pro Host und libvirt-Treiber
Übernommen von KubeVirt
Warum es ausgelassen wurde
KubeVirt betreibt die Gäste clusterweit; der Conductor steuert es über eine einzige RabbitMQ-Quorum-Queue, und der Scheduler ist eine Bibliothek des Conductors. Ein Agent pro Knoten meldet nur Ressourcen.
Warum die Lösung nicht beeinträchtigt ist
Starten, Stoppen, Größenänderung, Live-Migration und Drain laufen über KubeVirt; die Optionsgruppen für libvirt, VMware und Hyper-V entfallen mit den Treibern.
Quelle: openkeel-nova/docs/CONFORMANCE.md
Upstream veraltet oder ungenutzt
Veraltete Proxy-APIs (Images, Volumes, Netzwerke)
Warum es ausgelassen wurde
Die Proxys zu Glance, Cinder und Neutron (images, os-volumes, os-snapshots, os-networks, os-floating-ips, os-security-groups, os-hosts, os-baremetal-nodes) sind upstream veraltet.
Warum die Lösung nicht beeinträchtigt ist
Diese Routen antworten 501. Aktuelle Clients, darunter ok und Skyline, rufen Glance, Cinder und Neutron direkt auf, die OpenKeel bereitstellt.
Quelle: openkeel-nova/docs/PLAN.md
Von der Cloud-Native-Plattform übernommen
Suspend auf Festplatte
Übernommen von KubeVirt
Warum es ausgelassen wurde
KubeVirt kann den Gastspeicher nicht auf Festplatte sichern.
Warum die Lösung nicht beeinträchtigt ist
suspend wird angenommen, stoppt aber die VM: Der Speicherzustand des Gasts geht verloren, und er startet bei resume neu. Disks und Daten bleiben erhalten.
Quelle: openkeel-nova/docs/CONFORMANCE.md
Von der Cloud-Native-Plattform übernommen
Warten auf network-vif-plugged und Timeouts beim VIF-Plugging
Übernommen von OVN CNI
Warum es ausgelassen wurde
KubeVirt startet den Gast, sobald das CNI-Plugin gesehen hat, dass OVN seine Ports programmiert hat; Nova hält keinen pausierten Gast mehr in Erwartung des Ereignisses.
Warum die Lösung nicht beeinträchtigt ist
Der Server bleibt in BUILD, bis Neutron seine Ports als ACTIVE meldet. Das Ereignis wird weiterhin angenommen, sodass Neutron unverändert bleibt und ein verlorenes Ereignis nichts kostet.
Quelle: openkeel-nova/docs/CONFORMANCE.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
Nova-Interaktionen
Dienstansicht, vom Diagramm-Skill aus dem OpenKeel-Modell generiert.
