Le istanze girano come VirtualMachine KubeVirt; conductor con lo scheduler integrato nel processo, un agente per nodo.
Go KubeVirt e CDIopenkeel-nova
Il modulo
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
Estratto da openkeel-nova/README.md (in inglese).
API REST
273 operazioni dell'API REST originale (route e azioni nel corpo) e il loro stato in OpenKeel.
Gli scambi degli esempi di API di Nova Python vengono riprodotti sul servizio Go, la concorrenza viene testata su Galera, e istanze guest KubeVirt reali vengono avviate e sottoposte a drain sul laboratorio.
Replay degli scambi registrati
Replay E2E degli esempi di API
Ogni scambio registrato degli esempi di API di Nova Python restituisce lo stesso stato e lo stesso corpo dal servizio Go, con un database nuovo per ogni file.
Esecuzione
make e2e (1233 file), su go-mysql-server e su MariaDB 11.4 con E2E_MYSQL_DSN; report in test/e2e/report.json.
Ultimo risultato 1957 / 2590 identici su entrambi i motori; le differenze residue riguardano soprattutto API non implementate (501) e test che simulano il database.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Test unitari e golden test
Vettori unitari, di policy e di flavor
La pipeline del router, i messaggi di validazione, le 214 regole di policy, la mappa degli stati, le risorse dello scheduler e la conversione da flavor a KubeVirt si comportano come specificato.
Esecuzione
make test; vettori di flavor in internal/driver/kubevirt/flavor_test.go.
Ultimo risultato Superato; vettori da flavor a KubeVirt 6 / 6.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Concorrenza su Galera
Concorrenza su MariaDB Galera
Quote, nomi univoci e azioni concorrenti reggono quando le richieste arrivano contemporaneamente da tre nodi Galera.
Esecuzione
test/galera su un cluster a 3 nodi: avvii concorrenti, coppie di chiavi, gruppi di server, creazioni con lo stesso nome e arresti.
Ultimo risultato Superato, 3 esecuzioni su 3: esattamente 10 server per una quota di 10 su 30 avvii, nessun 5xx.
Fonte: openkeel-nova/docs/CONFORMANCE.md
End-to-end su un laboratorio
NIC delle VM su porte Neutron, istanze guest reali
POST /servers con porte Neutron avvia istanze guest reali che ottengono i propri indirizzi Neutron, sono isolate tra progetti e sopravvivono alla migrazione a caldo.
Esecuzione
Cluster kind usa e getta, profilo openkeel-lab dataplane: OVN reale, KubeVirt v1.9.1, istanze guest cirros, Glance, Placement e Neutron reali.
Ultimo risultato Superato (2026-10-31); la migrazione a caldo tramite il conductor su un disco local-path è rifiutata da KubeVirt ed è coperta solo dai test unitari.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Scenario
kubectl drain di un nodo di calcolo
Un drain migra a caldo l'istanza guest e Nova adotta la migrazione: host, binding della porta, chassis OVN e allocazione Placement seguono.
Esecuzione
openkeel-lab/scripts/drain-test.sh sul laboratorio dataplane, con due server creati tramite POST /servers.
Ultimo risultato Superato (2026-10-31); un peer ha perso 1 ping su 55. Nessun disco condiviso migrato, nessun nodo svuotato completamente.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Tempest
Tempest compute
I test API compute di Tempest upstream su un Nova distribuito.
Esecuzione
Richiede un cluster kind con KubeVirt, CDI, Longhorn e gli altri servizi OpenKeel.
Ultimo risultato Non eseguito.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Escluso dal rewrite
Nova mantiene la sua API e il suo modello di scheduling ma affida l'hypervisor a KubeVirt, eliminando le celle, i servizi nova-compute per host e le API proxy deprecate.
Meccanismi interni semplificati
Cells v2, cell0 e build requests
Perché è stato escluso
Un deployment nativo Kubernetes esegue una sola cella: un unico schema contiene le tabelle di nova_api e del database di cella, e la riga dell'istanza viene scritta in un'unica operazione.
Perché la soluzione non ne risente
I concetti visibili nell'API (instance mappings, request specs, stati BUILD ed ERROR con faults) sono mantenuti, così i client vedono lo stesso ciclo di vita del server.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Gestito dalla piattaforma Cloud Native
nova-compute per host e driver libvirt
Gestito da KubeVirt
Perché è stato escluso
KubeVirt esegue i guest a livello di cluster; il conductor lo pilota tramite un'unica coda quorum RabbitMQ e lo scheduler è una libreria del conductor. Un agente per nodo si limita a segnalare le risorse.
Perché la soluzione non ne risente
Avvio, arresto, ridimensionamento, migrazione live e drain passano per KubeVirt; i gruppi di opzioni libvirt, VMware e Hyper-V scompaiono con i driver.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Obsoleto o inutilizzato upstream
API proxy deprecate (immagini, volumi, reti)
Perché è stato escluso
I proxy verso Glance, Cinder e Neutron (images, os-volumes, os-snapshots, os-networks, os-floating-ips, os-security-groups, os-hosts, os-baremetal-nodes) sono deprecati upstream.
Perché la soluzione non ne risente
Queste route rispondono 501. I client attuali, tra cui ok e Skyline, chiamano direttamente Glance, Cinder e Neutron, forniti da OpenKeel.
Fonte: openkeel-nova/docs/PLAN.md
Gestito dalla piattaforma Cloud Native
Sospensione su disco
Gestito da KubeVirt
Perché è stato escluso
KubeVirt non consente di salvare su disco la memoria del guest.
Perché la soluzione non ne risente
suspend è accettato ma arresta la VM: lo stato della memoria del guest va perso e il guest si riavvia al resume. Dischi e dati sono conservati.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Gestito dalla piattaforma Cloud Native
Attesa di network-vif-plugged e timeout di collegamento delle VIF
Gestito da OVN CNI
Perché è stato escluso
KubeVirt avvia il guest non appena il plugin CNI ha visto OVN programmarne le porte; Nova non mantiene più un guest in pausa in attesa dell'evento.
Perché la soluzione non ne risente
Il server resta in BUILD finché Neutron non segnala le sue porte come ACTIVE. L'evento è ancora accettato, quindi Neutron resta invariato e un evento perso non ha alcun costo.
Fonte: openkeel-nova/docs/CONFORMANCE.md
Qui è elencato solo ciò che è stato escluso per scelta progettuale; il lavoro non ancora svolto si trova nei Known gaps del docs/CONFORMANCE.md del modulo. Tutti i moduli
Interazioni Nova
Vista del servizio generata dalla skill dei diagrammi a partire dal modello OpenKeel.
