OpenKeel: the sovereign French Cloud solution of the inherent group, with a European reach Discover inherent

Components · Storage

Manila

Multi-tenant NFS shares: one NFS-Ganesha gateway per share network, inside the tenant network.

Go NFS-Ganeshaopenkeel-manila

The module

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.

  • Go module: github.com/openkeel/openkeel-manila
  • Binaries: manila-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.
  • Back end: multi-tenant (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)
  • 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

Excerpt from openkeel-manila/README.md (in English).

REST API

258 operations of the original REST API (routes and body actions), and their state in OpenKeel.

  • 132Implemented
  • 126Not implemented

How compatibility is tested

Python Manila's recorded scenarios are replayed in order against the Go service, the Neutron contract is exercised, and tenant shares were mounted on a lab cluster.

Replay of recorded exchanges

E2E replay of recorded scenarios

283 exchanges of 29 ordered scenarios, with three back ends and the adapter's fake Neutron, give the same status, headers and body.

How it runs

go test -tags e2e ./test/e2e/; E2E_STRICT=1 passes with test/e2e/known-differences.txt.

Latest result 279 / 283 identical, the 4 differences explained (two Python bugs not reproduced).

Source: openkeel-manila/docs/CONFORMANCE.md

Client contract

Client flows

The recorded flows of python-manilaclient/OSC, Manila CSI, Skyline and manila-ui work unchanged at their microversions.

How it runs

Their recorded flows are part of the replay.

Latest result Replay identically.

Source: openkeel-manila/docs/CONFORMANCE.md

Client contract

Neutron contract

The six Neutron requests Manila sends (extensions, networks, subnets, port create, list and delete) match the recorded calls.

How it runs

Exercised by the replay against a Go port of the adapter's fake Neutron.

Source: openkeel-manila/docs/CONFORMANCE.md

End to end on a lab

Tenant share on a lab cluster

A project member creates a share network and share; a client mounts it over NFSv4.1 through OVN, others are refused; deletion cleans up.

How it runs

scripts/manila-test.sh on openkeel-lab profile manila-dataplane (kind, two OVN chassis).

Latest result Validated on a cluster (2026-11-02) for the openkeel-ovn attachment; kube-ovn and multus not validated.

Source: openkeel-manila/docs/CONFORMANCE.md

Left out of the rewrite

Manila keeps its API and scheduler but serves NFS shares from NFS-Ganesha gateways on block CSI volumes, which removes vendor drivers, the RPC bus, CIFS and in-place revert.

Done by the Cloud Native platform

Vendor share drivers

Taken over by NFS-Ganesha on CSI (Longhorn)

Why it was left out

One multi-tenant back end (DHSS=True): a Ganesha gateway per share network, attached to the tenant network through a Neutron port, with a Longhorn volume per share.

Why the solution is not affected

Manila CSI, manilaclient, Skyline and manila-ui replay their flows identically; tenant isolation comes from Neutron and per-export access lists.

Source: openkeel-manila/docs/CONFORMANCE.md

Internal machinery simplified

RabbitMQ RPC and host-local locks

Taken over by Kubernetes Leases

Why it was left out

Casts become database tasks claimed with a lease; capability reports are rows; one manila-share replica per back end holds a Kubernetes Lease.

Why the solution is not affected

No RabbitMQ for Manila and crashed workers' tasks are taken over. Python Manila services cannot run beside the Go ones: migration is a cut-over.

Source: openkeel-manila/docs/CONFORMANCE.md

Done by the Cloud Native platform

CIFS shares and in-place snapshot revert

Taken over by CSI

Why it was left out

The ganesha back end serves NFS only, and CSI cannot replace a volume in place.

Why the solution is not affected

CIFS is refused and revert_to_snapshot_support is reported False; new shares can still be created from snapshots.

Source: openkeel-manila/docs/CONFORMANCE.md

Only what was left out by design is listed here; the work not done yet is in the Known gaps of the module's docs/CONFORMANCE.md. Every module

Manila interactions

Service view generated by the diagram skill from the OpenKeel model.

Diagram openkeel-manila.svg Full screen
The 2 interactions of the model
FromToProtocolWhat
Manila APIManila share driverRabbitMQRPC create/extend
Manila share driverCSI driver (Longhorn)Kubernetes APIPVC (RWX filesystem)

Specifications