Les volumes bloc sont des PVC d'une StorageClass CSI (Rook-Ceph, Longhorn, NetApp, Huawei Dorado, Pure Storage), avec snapshots CSI et sauvegardes cinder-backup.
Go Tout CSI blocopenkeel-cinder
Le module
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
Extrait de openkeel-cinder/README.md (en anglais).
API REST
218 opérations de l'API REST d'origine (routes et actions de corps), et leur état dans OpenKeel.
Les échanges des tests fonctionnels de Cinder Python sont rejoués contre le service Go, le contrat d'attachement de Nova est testé, et la concurrence est vérifiée sur Galera.
Rejeu des échanges enregistrés
Rejeu E2E des tests fonctionnels
967 échanges de 196 tests fonctionnels Python donnent le même statut et le même corps, avec la fixture des tests fonctionnels émulée.
Exécution
make e2e, sur go-mysql-server et MariaDB 11.4 (E2E_MYSQL_DSN) ; E2E_STRICT=1 réussit avec test/e2e/known-differences.txt.
Dernier résultat 832 / 967 identiques (834 sur MariaDB) ; dans le périmètre seul, 832 / 854 (97.4 %), le reste étant groups et manage (hors périmètre).
Source : openkeel-cinder/docs/CONFORMANCE.md
Contrat client
Contrat d'attachement Nova
L'API des attachements en 3.44, la mise à jour et la suppression idempotentes, la règle du jeton de service et les statuts d'erreur que Nova interprète correspondent à ses attentes.
Exécution
TestNovaAttachmentFlow, tests du routeur et TestQuotaExceeded.
Dernier résultat Testé ; os-reimage et les événements externes Nova sont implémentés mais non rejoués contre Nova.
Source : openkeel-cinder/docs/CONFORMANCE.md
Tests unitaires et golden tests
Tests unitaires, de politique et de flux
Les personas de politique sur 161 des 167 règles par défaut, les vecteurs de quota et de transfert, les règles du routeur et le pilote CSI se comportent comme spécifié.
Exécution
go test ./... (13 packages), pilote CSI sur simulacres client-go.
Dernier résultat Tous réussis.
Source : openkeel-cinder/docs/CONFORMANCE.md
Concurrence sur Galera
Concurrence sur MariaDB Galera
Quota et réservation tiennent lorsque les créations arrivent simultanément par trois nœuds Galera.
Exécution
make galera-test sur un cluster à 3 nœuds : 30 créations pour un quota de 10, 9 os-reserve concurrents.
Dernier résultat Réussi, 3 exécutions sur 3 : exactement 10 × 202, 20 × 413, aucun 5xx ; un seul gagnant os-reserve.
Source : openkeel-cinder/docs/CONFORMANCE.md
Tempest
Tempest et rejeux de clients
Tempest tempest/api/volume, cinder-tempest-plugin et rejeux des appels de cinderclient, Nova et du store Glance.
Exécution
Nécessitent un cluster kind avec Keystone, Longhorn, CDI et KubeVirt ; aucune invocation client enregistrée n'existe.
Dernier résultat Non exécuté.
Source : openkeel-cinder/docs/CONFORMANCE.md
Écarté de la réécriture
Cinder conserve l'API de volumes mais délègue le chemin de données à CSI (Longhorn par défaut), ce qui supprime les drivers constructeurs, la migration et la réplication entre backends, ainsi que la topologie RPC.
Assuré par la plateforme Cloud Native
Drivers de volumes constructeurs et FC zone manager
Repris par CSI (Longhorn par défaut)
Pourquoi c'est écarté
Chaque backend est une StorageClass CSI avec snapshots CSI et hotplug KubeVirt ; les informations de connexion sont un kubernetes_pvc que consomme le Nova d'OpenKeel.
Pourquoi la solution n'est pas affectée
Nova, le store cinder de Glance, cinderclient et Skyline utilisent la même API. Tout stockage doté d'un driver CSI peut servir de backend.
Source : openkeel-cinder/docs/CONFORMANCE.md
Assuré par la plateforme Cloud Native
Migration de volumes entre backends
Repris par CSI
Pourquoi c'est écarté
La copie de données entre StorageClasses passe par retype avec la politique de migration on-demand.
Pourquoi la solution n'est pas affectée
os-migrate_volume répond 400 avec un message qui renvoie vers os-retype, qui déplace les données.
Source : openkeel-cinder/docs/CONFORMANCE.md
Assuré par la plateforme Cloud Native
Réplication Cinder et failover_host
Repris par CSI
Pourquoi c'est écarté
Les backends CSI n'ont pas de réplication gérée par Cinder.
Pourquoi la solution n'est pas affectée
failover_host répond 400 'no replication target configured'. La redondance est celle du backend de stockage, configurée hors de l'API Cinder.
Source : openkeel-cinder/docs/CONFORMANCE.md
Assuré par la plateforme Cloud Native
Clé Barbican par volume chiffré
Repris par Volumes chiffrés Longhorn
Pourquoi c'est écarté
Le chiffrement est assuré par la StorageClass : le chemin de Cinder n'a pas besoin de gestionnaire de clés.
Pourquoi la solution n'est pas affectée
Les types de volumes chiffrés fonctionnent toujours ; un identifiant de clé fixe est enregistré et masqué dans les vues 3.64.
Source : openkeel-cinder/docs/CONFORMANCE.md
Mécanique interne simplifiée
Casts RPC et ordonnancement sur les statistiques par pool
Pourquoi c'est écarté
L'API enregistre l'état transitoire et les workers interrogent la base ; les drivers CSI ne remontent pas de capacité, il y a donc un pool par backend et par AZ.
Pourquoi la solution n'est pas affectée
Les états des volumes et les réponses de l'API sont inchangés ; les opérations interrompues sont reprises au passage suivant, si bien que workers/cleanup renvoie des listes vides.
Source : openkeel-cinder/docs/CONFORMANCE.md
Mécanique interne simplifiée
Clusters actif-actif et os-hosts
Repris par Kubernetes Leases
Pourquoi c'est écarté
Chaque worker détient un Lease Kubernetes : les clusters actif-actif de Cinder n'existent donc pas.
Pourquoi la solution n'est pas affectée
Les listes de clusters et d'os-hosts sont vides et les écritures répondent 501 ; la haute disponibilité vient de la reprise du Lease.
Source : openkeel-cinder/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 Cinder
Vue « service » générée par la skill diagramme depuis le modèle d'OpenKeel.
