Instances exécutées comme VirtualMachines KubeVirt ; conductor avec le scheduler intégré, un agent par nœud.
Go KubeVirt et CDIopenkeel-nova
Le module
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
Extrait de openkeel-nova/README.md (en anglais).
API REST
273 opérations de l'API REST d'origine (routes et actions de corps), et leur état dans OpenKeel.
Les échanges des exemples d'API de Nova Python sont rejoués contre le service Go, la concurrence est testée sur Galera, et de vrais invités KubeVirt sont démarrés puis drainés sur le lab.
Rejeu des échanges enregistrés
Rejeu E2E des exemples d'API
Chaque échange enregistré des exemples d'API de Nova Python donne le même statut et le même corps depuis le service Go, sur une base de données neuve par fichier.
Exécution
make e2e (1233 fichiers), sur go-mysql-server et sur MariaDB 11.4 avec E2E_MYSQL_DSN ; rapport dans test/e2e/report.json.
Dernier résultat 1957 / 2590 identiques sur les deux moteurs ; les différences restantes sont surtout des API non implémentées (501) et des tests qui simulent la base de données.
Source : openkeel-nova/docs/CONFORMANCE.md
Tests unitaires et golden tests
Vecteurs unitaires, de politique et de flavor
Le pipeline du routeur, les messages de validation, les 214 règles de politique, la table d'états, les ressources du scheduler et la conversion flavor vers KubeVirt se comportent comme spécifié.
Exécution
make test ; vecteurs de flavor dans internal/driver/kubevirt/flavor_test.go.
Dernier résultat Réussi ; vecteurs flavor vers KubeVirt 6 / 6.
Source : openkeel-nova/docs/CONFORMANCE.md
Concurrence sur Galera
Concurrence sur MariaDB Galera
Quotas, noms uniques et actions concurrentes tiennent lorsque les requêtes arrivent simultanément par trois nœuds Galera.
Exécution
test/galera sur un cluster à 3 nœuds : démarrages concurrents, paires de clés, groupes de serveurs, créations de même nom et arrêts.
Dernier résultat Réussi, 3 exécutions sur 3 : exactement 10 serveurs pour un quota de 10 sur 30 démarrages, aucun 5xx.
Source : openkeel-nova/docs/CONFORMANCE.md
De bout en bout sur un lab
Cartes réseau de VM sur des ports Neutron, vrais invités
POST /servers avec des ports Neutron démarre de vrais invités qui obtiennent leurs adresses Neutron, sont isolés entre projets et survivent à la migration à chaud.
Dernier résultat Réussi (2026-10-31) ; la migration à chaud via le conductor sur un disque local-path est refusée par KubeVirt et couverte uniquement par des tests unitaires.
Source : openkeel-nova/docs/CONFORMANCE.md
Scénario
kubectl drain d'un nœud de calcul
Un drain migre l'invité à chaud, et Nova adopte la migration : hôte, liaison de port, chassis OVN et allocation Placement suivent.
Exécution
openkeel-lab/scripts/drain-test.sh sur le lab dataplane, avec deux serveurs créés par POST /servers.
Dernier résultat Réussi (2026-10-31) ; un pair a perdu 1 ping sur 55. Aucun disque partagé migré, aucun nœud entièrement vidé.
Source : openkeel-nova/docs/CONFORMANCE.md
Tempest
Tempest compute
Les tests d'API compute Tempest amont contre un Nova déployé.
Exécution
Nécessite un cluster kind avec KubeVirt, CDI, Longhorn et les autres services OpenKeel.
Dernier résultat Non exécuté.
Source : openkeel-nova/docs/CONFORMANCE.md
Écarté de la réécriture
Nova conserve son API et son modèle d'ordonnancement mais confie l'hyperviseur à KubeVirt, ce qui supprime les cellules, les services nova-compute par hôte et les API proxy dépréciées.
Mécanique interne simplifiée
Cells v2, cell0 et build requests
Pourquoi c'est écarté
Un déploiement natif Kubernetes exécute une seule cellule : un même schéma contient les tables de nova_api et de la base de cellule, et la ligne d'instance est écrite d'un coup.
Pourquoi la solution n'est pas affectée
Les concepts visibles par l'API (instance mappings, request specs, états BUILD et ERROR avec faults) sont conservés : les clients voient le même cycle de vie de serveur.
Source : openkeel-nova/docs/CONFORMANCE.md
Assuré par la plateforme Cloud Native
nova-compute par hôte et drivers libvirt
Repris par KubeVirt
Pourquoi c'est écarté
KubeVirt exécute les invités à l'échelle du cluster ; le conductor le pilote via une seule file quorum RabbitMQ et le scheduler est une bibliothèque du conductor. Un agent par nœud ne fait que remonter les ressources.
Pourquoi la solution n'est pas affectée
Démarrage, arrêt, redimensionnement, migration à chaud et drain passent par KubeVirt ; les groupes d'options libvirt, VMware et Hyper-V disparaissent avec les drivers.
Source : openkeel-nova/docs/CONFORMANCE.md
Obsolète ou inutilisé en amont
API proxy dépréciées (images, volumes, réseaux)
Pourquoi c'est écarté
Les proxys vers Glance, Cinder et Neutron (images, os-volumes, os-snapshots, os-networks, os-floating-ips, os-security-groups, os-hosts, os-baremetal-nodes) sont dépréciés en amont.
Pourquoi la solution n'est pas affectée
Ces routes répondent 501. Les clients actuels, dont ok et Skyline, appellent directement Glance, Cinder et Neutron, qu'OpenKeel fournit.
Source : openkeel-nova/docs/PLAN.md
Assuré par la plateforme Cloud Native
Suspension sur disque
Repris par KubeVirt
Pourquoi c'est écarté
KubeVirt ne sait pas sauvegarder la mémoire de l'invité sur disque.
Pourquoi la solution n'est pas affectée
suspend est accepté mais arrête la VM : l'état mémoire de l'invité est perdu et il redémarre au resume. Les disques et les données sont conservés.
Source : openkeel-nova/docs/CONFORMANCE.md
Assuré par la plateforme Cloud Native
Attente de network-vif-plugged et timeouts de branchement des VIF
Repris par OVN CNI
Pourquoi c'est écarté
KubeVirt démarre l'invité dès que le plugin CNI a vu OVN programmer ses ports ; Nova ne garde plus un invité en pause en attendant l'événement.
Pourquoi la solution n'est pas affectée
Le serveur reste en BUILD jusqu'à ce que Neutron signale ses ports ACTIVE. L'événement est toujours accepté : Neutron est inchangé et un événement perdu ne coûte rien.
Source : openkeel-nova/docs/CONFORMANCE.md
Seul ce qui a été écarté par choix de conception figure ici ; le travail pas encore fait se trouve dans les Known gaps du docs/CONFORMANCE.md du module. Tous les modules
Interactions de Nova
Vue « service » générée par la skill diagramme depuis le modèle d'OpenKeel.
