Los volúmenes de bloque son PVC de una StorageClass CSI (Rook-Ceph, Longhorn, NetApp, Huawei Dorado, Pure Storage), con snapshots CSI y copias de seguridad de cinder-backup.
Go Cualquier CSI de bloqueopenkeel-cinder
El módulo
OpenKeel implementation in Go of OpenStack Cinder, the Block Storage API v3, 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 (Nova, Glance's cinder store, python-cinderclient, Skyline): same routes, status codes, error bodies, microversions 3.0–3.71 and policies. Volumes are Kubernetes PVCs on a block CSI StorageClass (Longhorn by default), snapshots and backups are CSI VolumeSnapshots, volumes from images are CDI clones, and attachments are KubeVirt hotplugs. What is reproduced and what differs is in docs/CONFORMANCE.md; the security checklist is in docs/SECURITY.md; the build plan with the status of every operation is in docs/PLAN.md.
Go module: github.com/openkeel/openkeel-cinder
Binaries (one image): | Binary | Role | Ports | |---|---|---| | cinder-api | REST API v3; also -migrate for the database migrations | 8776, admin 9090 | | cinder-scheduler | places volumes on backends and backups on backup hosts, purges expired reservations and messages | admin 9090 | | cinder-volume | drives PVCs, VolumeSnapshots, DataVolumes and PV handovers for the volumes of its backends | admin 9090 | | cinder-backup | creates, deletes and restores backups (VolumeSnapshots of the backup class) | admin 9090 | The workers poll the database for transient statuses and elect one active replica each with a Kubernetes Lease.
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-cinder/README.md (en inglés).
API REST
218 operaciones de la API REST original (rutas y acciones de cuerpo) y su estado en OpenKeel.
Los intercambios de los tests funcionales de Cinder en Python se reproducen contra el servicio Go, se prueba el contrato de attachments de Nova y se verifica la concurrencia en Galera.
Replay de los intercambios grabados
Replay E2E de los tests funcionales
967 intercambios de 196 tests funcionales de Python dan el mismo estado y el mismo cuerpo, con el fixture de los tests funcionales emulado.
Ejecución
make e2e, en go-mysql-server y MariaDB 11.4 (E2E_MYSQL_DSN); E2E_STRICT=1 se supera con test/e2e/known-differences.txt.
Último resultado 832 / 967 idénticos (834 en MariaDB); solo dentro del alcance, 832 / 854 (97.4 %), siendo el resto groups y manage (fuera del alcance).
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Contrato de cliente
Contrato de attachments de Nova
La API de attachments en 3.44, la actualización y eliminación idempotentes, la regla del token de servicio y los estados de error que Nova interpreta coinciden con sus expectativas.
Ejecución
TestNovaAttachmentFlow, tests del router y TestQuotaExceeded.
Último resultado Probado; os-reimage y los eventos externos de Nova están implementados pero no se reproducen contra Nova.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Tests unitarios y golden tests
Tests unitarios, de políticas y de flujos
Las personas de políticas en 161 de las 167 reglas por defecto, los vectores de cuota y de transferencia, las reglas del router y el driver CSI se comportan según lo especificado.
Ejecución
go test ./... (13 paquetes), driver CSI sobre simulaciones de client-go.
Último resultado Todos superados.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Concurrencia en Galera
Concurrencia en MariaDB Galera
La cuota y la reserva se mantienen cuando las creaciones llegan simultáneamente a través de tres nodos Galera.
Ejecución
make galera-test en un clúster de 3 nodos: 30 creaciones para una cuota de 10, 9 os-reserve concurrentes.
Último resultado Superado, 3 ejecuciones de 3: exactamente 10 × 202, 20 × 413, ningún 5xx; un único ganador de os-reserve.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Tempest
Tempest y replays de clientes
Tempest tempest/api/volume, cinder-tempest-plugin y replays de llamadas de cinderclient, Nova y el store de Glance.
Ejecución
Requieren un clúster kind con Keystone, Longhorn, CDI y KubeVirt; no existen invocaciones de cliente grabadas.
Último resultado No ejecutado.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Excluido del rewrite
Cinder conserva la API de volúmenes pero delega la ruta de datos en CSI (Longhorn por defecto), lo que elimina los drivers de fabricante, la migración y replicación entre backends y la topología RPC.
Asumido por la plataforma Cloud Native
Drivers de volumen de fabricantes y FC zone manager
Asumido por CSI (Longhorn por defecto)
Por qué se excluyó
Cada backend es una StorageClass CSI con snapshots CSI y hotplug de KubeVirt; la información de conexión es un kubernetes_pvc que consume el Nova de OpenKeel.
Por qué la solución no se ve afectada
Nova, el store cinder de Glance, cinderclient y Skyline usan la misma API. Cualquier almacenamiento con un driver CSI puede ser un backend.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Asumido por la plataforma Cloud Native
Migración de volúmenes entre backends
Asumido por CSI
Por qué se excluyó
La copia de datos entre StorageClasses se realiza con retype y la política de migración on-demand.
Por qué la solución no se ve afectada
os-migrate_volume responde 400 con un mensaje que remite a os-retype, que traslada los datos.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Asumido por la plataforma Cloud Native
Replicación de Cinder y failover_host
Asumido por CSI
Por qué se excluyó
Los backends CSI no tienen replicación gestionada por Cinder.
Por qué la solución no se ve afectada
failover_host responde 400 'no replication target configured'. La redundancia es la del propio backend de almacenamiento, configurada fuera de la API de Cinder.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Asumido por la plataforma Cloud Native
Clave de Barbican por volumen cifrado
Asumido por Volúmenes cifrados de Longhorn
Por qué se excluyó
El cifrado lo realiza la StorageClass, por lo que la ruta de Cinder no necesita gestor de claves.
Por qué la solución no se ve afectada
Los tipos de volumen cifrados siguen funcionando; se registra un identificador de clave fijo, oculto en las vistas 3.64.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Mecánica interna simplificada
Casts RPC y planificación según estadísticas por pool
Por qué se excluyó
La API registra el estado transitorio y los workers consultan la base de datos; los drivers CSI no notifican capacidad, por lo que hay un pool por backend y AZ.
Por qué la solución no se ve afectada
Los estados de los volúmenes y las respuestas de la API no cambian; las operaciones interrumpidas se reanudan en la siguiente pasada, por lo que workers/cleanup devuelve listas vacías.
Fuente: openkeel-cinder/docs/CONFORMANCE.md
Mecánica interna simplificada
Clústeres activo-activo y os-hosts
Asumido por Kubernetes Leases
Por qué se excluyó
Cada worker mantiene un Lease de Kubernetes, por lo que no existen los clústeres activo-activo de Cinder.
Por qué la solución no se ve afectada
Las listas de clústeres y os-hosts están vacías y las escrituras responden 501; la alta disponibilidad procede de la toma del Lease.
Fuente: openkeel-cinder/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 Cinder
Vista de servicio generada por la skill de diagramas a partir del modelo de OpenKeel.
