OpenKeel: la soluzione Cloud sovrana, francese e di portata europea, del gruppo inherent Scopri inherent
Componenti · Storage
Share NFS multi-tenant: un gateway NFS-Ganesha per share network, all'interno della rete del tenant.
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)Estratto da openkeel-manila/README.md (in inglese).
258 operazioni dell'API REST originale (route e azioni nel corpo) e il loro stato in OpenKeel.
Gli scenari registrati di Manila Python vengono riprodotti in ordine sul servizio Go, il contratto Neutron viene verificato e condivisioni di tenant sono state montate su un cluster di laboratorio.
283 scambi di 29 scenari ordinati, con tre back end e il Neutron simulato dell'adattatore, restituiscono lo stesso stato, le stesse intestazioni e lo stesso corpo.
go test -tags e2e ./test/e2e/; E2E_STRICT=1 superato con test/e2e/known-differences.txt.
Ultimo risultato 279 / 283 identici, con le 4 differenze spiegate (due bug di Python non riprodotti).
Fonte: openkeel-manila/docs/CONFORMANCE.md
I flussi registrati di python-manilaclient/OSC, Manila CSI, Skyline e manila-ui funzionano senza modifiche alle rispettive microversioni.
I loro flussi registrati fanno parte del replay.
Ultimo risultato Riproducono in modo identico.
Fonte: openkeel-manila/docs/CONFORMANCE.md
Le sei richieste a Neutron inviate da Manila (estensioni, reti, subnet, creazione, elenco ed eliminazione di porte) corrispondono alle chiamate registrate.
Verificato dal replay su un porting in Go del Neutron simulato dell'adattatore.
Fonte: openkeel-manila/docs/CONFORMANCE.md
Un membro del progetto crea una share network e una condivisione; un client la monta in NFSv4.1 tramite OVN, gli altri vengono rifiutati; l'eliminazione ripulisce tutto.
scripts/manila-test.sh sul profilo openkeel-lab manila-dataplane (kind, due chassis OVN).
Ultimo risultato Convalidato su un cluster (2026-11-02) per l'attachment openkeel-ovn; kube-ovn e multus non convalidati.
Fonte: openkeel-manila/docs/CONFORMANCE.md
Manila mantiene la sua API e il suo scheduler ma serve share NFS da gateway NFS-Ganesha su volumi CSI a blocchi, eliminando i driver dei vendor, il bus RPC, CIFS e il ripristino sul posto.
Gestito da NFS-Ganesha su CSI (Longhorn)
Un unico back end multi-tenant (DHSS=True): un gateway Ganesha per share network, collegato alla rete del tenant tramite una porta Neutron, con un volume Longhorn per share.
Manila CSI, manilaclient, Skyline e manila-ui riproducono i loro flussi in modo identico; l'isolamento dei tenant deriva da Neutron e dalle liste di accesso per export.
Fonte: openkeel-manila/docs/CONFORMANCE.md
Gestito da Kubernetes Leases
I cast diventano task nel database acquisiti tramite un lease; i report di capacità sono righe; una replica di manila-share per back end detiene un Lease Kubernetes.
Nessun RabbitMQ per Manila, e i task dei worker in crash vengono ripresi. I servizi Manila Python non possono girare accanto a quelli Go: la migrazione è un passaggio netto.
Fonte: openkeel-manila/docs/CONFORMANCE.md
Gestito da CSI
Il back end ganesha serve solo NFS, e CSI non può sostituire un volume sul posto.
CIFS viene rifiutato e revert_to_snapshot_support è segnalato come False; è sempre possibile creare nuove share a partire da snapshot.
Fonte: openkeel-manila/docs/CONFORMANCE.md
Qui è elencato solo ciò che è stato escluso per scelta progettuale; il lavoro non ancora svolto si trova nei Known gaps del docs/CONFORMANCE.md del modulo. Tutti i moduli
Vista del servizio generata dalla skill dei diagrammi a partire dal modello OpenKeel.
Schermo intero| Da | A | Protocollo | Cosa |
|---|---|---|---|
| Manila API | Manila share driver | RabbitMQ | RPC create/extend |
| Manila share driver | CSI driver (Longhorn) | API Kubernetes | PVC (RWX filesystem) |
Branch stable-2026.2 · 9 file
Leggi la reverse-specI volumi a blocchi sono PVC di una StorageClass CSI (Rook-Ceph, Longhorn, NetApp, Huawei Dorado, Pure Storage), con snapshot CSI e backup cinder-backup.
Immagini archiviate in PVC a blocchi tramite i DataVolume di CDI; i quattro metodi di importazione interoperabili.
Storage a oggetti: Rook-Ceph e il suo gateway RGW per le API S3 e Swift.
Driver CSI in Go per Pure Storage FlashArray su iSCSI: snapshot, cloni, espansione, blocco RWX per KubeVirt. Prototipo.