OpenKeel: die souveräne französische Cloud-Lösung mit europäischer Reichweite der inherent-Gruppe inherent entdecken
Komponenten · Speicher
Mandantenfähige NFS-Shares: ein NFS-Ganesha-Gateway pro Share-Netz, innerhalb des Mandantennetzes.
OpenKeel implementation in Go of OpenStack Manila (manila-api, manila-scheduler, manila-share), 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.
github.com/openkeel/openkeel-manilamanila-api (API on port 8786, health and metrics on 9090), manila-scheduler and manila-share (workers fed by the database task queue, no RabbitMQ), manila-ganesha-agent (side-car of the NFS-Ganesha gateway pods). Each process binary is the same program with another default -process.driver_handles_share_servers: true): one NFS-Ganesha gateway pod per share network subnet, attached to the tenant network through a Neutron port, Longhorn RWO volumes behind it, CSI snapshots (07 § 3.5; design in docs/CONFORMANCE.md D1)Auszug aus openkeel-manila/README.md (auf Englisch).
258 Operationen der Original-REST-API (Routen und Body-Aktionen) und ihr Status in OpenKeel.
Die aufgezeichneten Szenarien von Python-Manila werden in Reihenfolge gegen den Go-Dienst wiedergegeben, der Neutron-Vertrag wird geprüft, und Mandanten-Freigaben wurden auf einem Lab-Cluster gemountet.
283 Austausche aus 29 geordneten Szenarien liefern mit drei Back-Ends und dem Fake-Neutron des Adapters denselben Status, dieselben Header und denselben Body.
go test -tags e2e ./test/e2e/; E2E_STRICT=1 besteht mit test/e2e/known-differences.txt.
Letztes Ergebnis 279 / 283 identisch, die 4 Unterschiede erklärt (zwei Python-Fehler nicht nachgebildet).
Quelle: openkeel-manila/docs/CONFORMANCE.md
Die aufgezeichneten Abläufe von python-manilaclient/OSC, Manila CSI, Skyline und manila-ui funktionieren unverändert mit ihren Microversions.
Ihre aufgezeichneten Abläufe sind Teil des Replays.
Letztes Ergebnis Identisches Replay.
Quelle: openkeel-manila/docs/CONFORMANCE.md
Die sechs Neutron-Anfragen von Manila (Erweiterungen, Netze, Subnetze, Port erstellen, auflisten und löschen) entsprechen den aufgezeichneten Aufrufen.
Durch das Replay gegen eine Go-Portierung des Fake-Neutron des Adapters geprüft.
Quelle: openkeel-manila/docs/CONFORMANCE.md
Ein Projektmitglied erstellt ein Share Network und eine Freigabe; ein Client mountet sie per NFSv4.1 über OVN, andere werden abgewiesen; das Löschen räumt auf.
scripts/manila-test.sh auf dem openkeel-lab-Profil manila-dataplane (kind, zwei OVN-Chassis).
Letztes Ergebnis Auf einem Cluster validiert (2026-11-02) für das Attachment openkeel-ovn; kube-ovn und multus nicht validiert.
Quelle: openkeel-manila/docs/CONFORMANCE.md
Manila behält seine API und seinen Scheduler, stellt NFS-Shares aber über NFS-Ganesha-Gateways auf Block-CSI-Volumes bereit; damit entfallen Herstellertreiber, der RPC-Bus, CIFS und der Revert vor Ort.
Übernommen von NFS-Ganesha auf CSI (Longhorn)
Ein einziges mandantenfähiges Back End (DHSS=True): ein Ganesha-Gateway pro Share-Netzwerk, über einen Neutron-Port an das Mandantennetz angebunden, mit einem Longhorn-Volume pro Share.
Manila CSI, manilaclient, Skyline und manila-ui spielen ihre Abläufe identisch ab; die Mandantenisolation ergibt sich aus Neutron und Zugriffslisten pro Export.
Quelle: openkeel-manila/docs/CONFORMANCE.md
Übernommen von Kubernetes Leases
Casts werden zu Datenbank-Tasks, die per Lease beansprucht werden; Capability-Berichte sind Zeilen; eine manila-share-Replik pro Back End hält einen Kubernetes-Lease.
Kein RabbitMQ für Manila, und Tasks abgestürzter Worker werden übernommen. Python-Manila-Dienste können nicht neben den Go-Diensten laufen: Die Migration ist eine Umstellung in einem Schritt.
Quelle: openkeel-manila/docs/CONFORMANCE.md
Übernommen von CSI
Das ganesha-Back-End stellt nur NFS bereit, und CSI kann ein Volume nicht vor Ort ersetzen.
CIFS wird abgewiesen und revert_to_snapshot_support wird als False gemeldet; neue Shares können weiterhin aus Snapshots erstellt werden.
Quelle: openkeel-manila/docs/CONFORMANCE.md
Hier ist nur aufgeführt, was bewusst ausgelassen wurde; noch nicht erledigte Arbeit steht in den Known gaps der docs/CONFORMANCE.md des Moduls. Alle Module
Dienstansicht, vom Diagramm-Skill aus dem OpenKeel-Modell generiert.
Vollbild| Von | Nach | Protokoll | Was |
|---|---|---|---|
| Manila API | Manila share driver | RabbitMQ | RPC create/extend |
| Manila share driver | CSI driver (Longhorn) | Kubernetes-API | PVC (RWX filesystem) |
Branch stable-2026.2 · 9 Dateien
Reverse-Spec lesenBlock-Volumes sind PVCs einer CSI-StorageClass (Rook-Ceph, Longhorn, NetApp, Huawei Dorado, Pure Storage), mit CSI-Snapshots und cinder-backup-Sicherungen.
Images, über CDI-DataVolumes in Block-PVCs gespeichert; die vier interoperablen Importmethoden.
Objektspeicher: Rook-Ceph und sein RGW-Gateway für die S3- und Swift-APIs.
Go-CSI-Treiber für Pure Storage FlashArray über iSCSI: Snapshots, Klone, Erweiterung, Block-RWX für KubeVirt. Prototyp.