Las instancias se ejecutan como VirtualMachines de KubeVirt; conductor con el scheduler integrado en el proceso, un agente por nodo.
Go KubeVirt y CDIopenkeel-nova
El módulo
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
Extracto de openkeel-nova/README.md (en inglés).
API REST
273 operaciones de la API REST original (rutas y acciones de cuerpo) y su estado en OpenKeel.
Los intercambios de los ejemplos de API de Nova en Python se reproducen contra el servicio Go, la concurrencia se prueba en Galera y en el laboratorio se arrancan y drenan instancias KubeVirt reales.
Replay de los intercambios grabados
Replay E2E de los ejemplos de API
Cada intercambio grabado de los ejemplos de API de Nova en Python da el mismo estado y el mismo cuerpo desde el servicio Go, con una base de datos nueva por archivo.
Ejecución
make e2e (1233 archivos), en go-mysql-server y en MariaDB 11.4 con E2E_MYSQL_DSN; informe en test/e2e/report.json.
Último resultado 1957 / 2590 idénticos en ambos motores; las diferencias restantes son sobre todo API no implementadas (501) y tests que simulan la base de datos.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Tests unitarios y golden tests
Vectores unitarios, de políticas y de flavor
El pipeline del router, los mensajes de validación, las 214 reglas de políticas, la tabla de estados, los recursos del scheduler y la conversión de flavor a KubeVirt se comportan según lo especificado.
Ejecución
make test; vectores de flavor en internal/driver/kubevirt/flavor_test.go.
Último resultado Superado; vectores de flavor a KubeVirt 6 / 6.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Concurrencia en Galera
Concurrencia en MariaDB Galera
Las cuotas, los nombres únicos y las acciones concurrentes se mantienen cuando las peticiones llegan simultáneamente a través de tres nodos Galera.
Ejecución
test/galera en un clúster de 3 nodos: arranques concurrentes, pares de claves, grupos de servidores, creaciones con el mismo nombre y paradas.
Último resultado Superado, 3 ejecuciones de 3: exactamente 10 servidores para una cuota de 10 sobre 30 arranques, ningún 5xx.
Fuente: openkeel-nova/docs/CONFORMANCE.md
De extremo a extremo en un laboratorio
NIC de VM en puertos de Neutron, instancias reales
POST /servers con puertos de Neutron arranca instancias reales que obtienen sus direcciones de Neutron, están aisladas entre proyectos y sobreviven a la migración en vivo.
Último resultado Superado (2026-10-31); KubeVirt rechaza la migración en vivo a través del conductor sobre un disco local-path, que solo cubren los tests unitarios.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Escenario
kubectl drain de un nodo de cómputo
Un drain migra en vivo la instancia invitada y Nova adopta la migración: host, vinculación de puerto, chassis OVN y asignación de Placement la siguen.
Ejecución
openkeel-lab/scripts/drain-test.sh en el laboratorio dataplane, con dos servidores creados mediante POST /servers.
Último resultado Superado (2026-10-31); un par perdió 1 ping de 55. Ningún disco compartido migrado, ningún nodo vaciado por completo.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Tempest
Tempest compute
Los tests de API compute de Tempest upstream contra un Nova desplegado.
Ejecución
Requiere un clúster kind con KubeVirt, CDI, Longhorn y los demás servicios de OpenKeel.
Último resultado No ejecutado.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Excluido del rewrite
Nova conserva su API y su modelo de planificación, pero confía el hipervisor a KubeVirt, lo que elimina las celdas, los servicios nova-compute por host y las API proxy obsoletas.
Mecánica interna simplificada
Cells v2, cell0 y build requests
Por qué se excluyó
Un despliegue nativo de Kubernetes ejecuta una sola celda: un mismo esquema contiene las tablas de nova_api y de la base de datos de la celda, y la fila de la instancia se escribe de una vez.
Por qué la solución no se ve afectada
Los conceptos visibles en la API (instance mappings, request specs, estados BUILD y ERROR con faults) se conservan, de modo que los clientes ven el mismo ciclo de vida del servidor.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Asumido por la plataforma Cloud Native
nova-compute por host y drivers libvirt
Asumido por KubeVirt
Por qué se excluyó
KubeVirt ejecuta los invitados en todo el clúster; el conductor lo controla mediante una única cola quorum de RabbitMQ y el scheduler es una biblioteca del conductor. Un agente por nodo solo notifica recursos.
Por qué la solución no se ve afectada
Arranque, parada, redimensionamiento, migración en caliente y drenaje funcionan a través de KubeVirt; los grupos de opciones de libvirt, VMware e Hyper-V desaparecen con los drivers.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Obsoleto o sin uso en upstream
API proxy obsoletas (imágenes, volúmenes, redes)
Por qué se excluyó
Los proxies hacia Glance, Cinder y Neutron (images, os-volumes, os-snapshots, os-networks, os-floating-ips, os-security-groups, os-hosts, os-baremetal-nodes) están obsoletos en upstream.
Por qué la solución no se ve afectada
Estas rutas responden 501. Los clientes actuales, incluidos ok y Skyline, llaman directamente a Glance, Cinder y Neutron, que OpenKeel proporciona.
Fuente: openkeel-nova/docs/PLAN.md
Asumido por la plataforma Cloud Native
Suspensión a disco
Asumido por KubeVirt
Por qué se excluyó
KubeVirt no permite guardar la memoria del invitado en disco.
Por qué la solución no se ve afectada
suspend se acepta pero detiene la VM: el estado de la memoria del invitado se pierde y vuelve a arrancar en resume. Los discos y los datos se conservan.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Asumido por la plataforma Cloud Native
Espera de network-vif-plugged y timeouts de conexión de VIF
Asumido por OVN CNI
Por qué se excluyó
KubeVirt arranca el invitado en cuanto el plugin CNI ha visto a OVN programar sus puertos; Nova ya no mantiene un invitado en pausa a la espera del evento.
Por qué la solución no se ve afectada
El servidor permanece en BUILD hasta que Neutron notifica sus puertos como ACTIVE. El evento se sigue aceptando, por lo que Neutron no cambia y un evento perdido no tiene coste.
Fuente: openkeel-nova/docs/CONFORMANCE.md
Aquí solo figura lo que se excluyó por diseño; el trabajo aún no realizado está en los Known gaps del docs/CONFORMANCE.md del módulo. Todos los módulos
Interacciones Nova
Vista de servicio generada por la skill de diagramas a partir del modelo de OpenKeel.
