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

Get started

Reverse-spec · Services

manila — Scenarios

End-to-end scenarios — manila — branch stable/2026.2

Branch stable/2026.2 @ 4fbc4b4f3688 — repository https://opendev.org/openstack/manila — analysed on 2026-10-29

Each scenario below was run against the real API, scheduler and share manager (DummyDriver back ends alpha and beta) by the client scenarios of [_rewrite/tools/adapter_manila.py](_rewrite/tools/adapter_manila.py); the HTTP exchanges are in [_rewrite/exchanges_stable-2026.2.json](_rewrite/exchanges_stable-2026.2.json) and the RPC frames in [_rewrite/rpc-frames_stable-2026.2.json](_rewrite/rpc-frames_stable-2026.2.json). The scenario name is given for each one. Participants: the client (python-manilaclient, the Manila CSI driver), manila-api, MariaDB, RabbitMQ, manila-scheduler, manila-share (one service per back end) and the storage back end.

1. A Kubernetes PVC provisions a share (Manila CSI driver, NFS)

CreateVolume of the CSI controller: look the share up by name, create it, poll until available, then on NodeStage grant the node's IP and read the export locations (scenario csi-driver-flow). The CSI driver pins microversion 2.37 (cloud-provider-openstack:pkg/csi/manila/manilaclient/builder.go:33), switching to 2.45 for access rules and 2.65 for scheduler hints.

sequenceDiagram
  autonumber
  participant CSI as Manila CSI (gophercloud)
  participant API as manila-api
  participant DB as MariaDB
  participant MQ as RabbitMQ
  participant SCH as manila-scheduler
  participant SH as manila-share (host@backend)
  participant BE as storage back end
  CSI->>API: GET /v2/ (X-OpenStack-Manila-API-Version 2.37)
  API-->>CSI: 200 {"versions":[{"min_version":"2.0","version":"2.99"}]}
  CSI->>API: GET /v2/{project}/shares/detail?name=pvc-1234
  API-->>CSI: 200 {"shares": []}
  CSI->>API: POST /v2/{project}/shares {"share":{"share_proto":"NFS","size":1,"name":"pvc-1234","share_type":"default","metadata":{...}}}
  API->>DB: quota_reserve (SELECT … FOR UPDATE quota_usages), INSERT shares, share_instances (creating), commit
  API->>MQ: cast create_share_instance v1.2 (topic manila-scheduler)
  API-->>CSI: 200 {"share":{"status":"creating"}}
  MQ->>SCH: create_share_instance
  SCH->>SCH: filters (AZ, Capacity, Capabilities…) and weighers on cached pools
  SCH->>DB: UPDATE share_instances SET host='node-1@alpha#pool'
  SCH->>MQ: cast create_share_instance v1.4 (manila-share.node-1@alpha)
  MQ->>SH: create_share_instance
  SH->>BE: driver.create_share
  BE-->>SH: export locations
  SH->>DB: INSERT share_instance_export_locations, UPDATE status=available
  loop until available
    CSI->>API: GET /v2/{project}/shares/{id}
    API-->>CSI: 200 status
  end
  Note over CSI,API: NodeStage
  CSI->>API: GET /v2/{project}/share-access-rules?share_id={id} (2.45)
  CSI->>API: POST /shares/{id}/action {"allow_access":{"access_type":"ip","access_to":"192.168.0.10","access_level":"rw"}}
  API->>DB: INSERT share_access_map (queued_to_apply), access_rules_status=syncing
  API->>MQ: cast update_access v1.14 (manila-share.node-1@alpha)
  API-->>CSI: 200 {"access":{"state":"queued_to_apply"}}
  MQ->>SH: update_access
  SH->>BE: driver.update_access(all rules, add_rules=[rule])
  SH->>DB: rule active, access_rules_status=active
  CSI->>API: GET share-access-rules (poll until active)
  CSI->>API: GET /shares/{id}/export_locations
  API-->>CSI: 200 [{"path":"10.0.0.10:/…","preferred":true}, …]

Diagnostics: share stuck in creating → the scheduler did not receive or process the cast (RabbitMQ, scheduler logs "Failed to schedule_create_share"), or the share service of the chosen host is down (look at GET /services). Share in error → GET /messages?resource_id=<id> gives the reason (step 10 or 14); the CSI driver reads exactly this message (cloud-provider-openstack:pkg/csi/manila/util.go:133-141). Rule stuck in queued_to_apply → the share service never consumed update_access (host down) — the access rule stays queued and the PVC never mounts. Rule error → driver refused the client (look at the share service log).

2. Scheduling failure

Share type impossible requests share_backend_name=NO_SUCH_BACKEND (scenario no-valid-host).

sequenceDiagram
  autonumber
  participant C as client
  participant API as manila-api
  participant MQ as RabbitMQ
  participant SCH as manila-scheduler
  participant DB as MariaDB
  C->>API: POST /shares (share_type impossible)
  API-->>C: 200 creating
  API->>MQ: cast create_share_instance
  MQ->>SCH: create_share_instance
  SCH->>SCH: CapabilitiesFilter rejects every pool
  SCH->>DB: UPDATE share_instances status=error
  SCH->>DB: INSERT messages (action 001 allocate host, detail 008 FILTER_CAPABILITIES)
  SCH->>MQ: notification scheduler.create_share_instance (ERROR)
  C->>API: GET /messages?resource_id=…&message_level=ERROR
  API-->>C: "allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed."

Diagnostics: the detail code names the last filter that removed every host (manila/message/message_field.py:242-252); GET /scheduler-stats/pools/detail?share_type=<id> (admin) shows which pools match a type.

3. Resize (extend)

sequenceDiagram
  autonumber
  participant C as client
  participant API as manila-api
  participant DB as MariaDB
  participant MQ as RabbitMQ
  participant SCH as manila-scheduler
  participant SH as manila-share
  C->>API: POST /shares/{id}/action {"extend":{"new_size":2}}
  API->>DB: quota_reserve gigabytes +1, UPDATE status=extending
  API->>MQ: cast extend_share v1.11 (manila-scheduler)
  API-->>C: 202
  MQ->>SCH: extend_share (extend filters on the current pool)
  SCH->>MQ: cast extend_share (manila-share.<host>)
  MQ->>SH: extend_share
  SH->>SH: driver.extend_share(share, 2)
  alt success
    SH->>DB: size=2, status=available, reservation commit
  else driver error
    SH->>DB: status=extending_error, reservation rollback, message DRIVER_FAILED_EXTEND
  end

(scenarios manilaclient-share-lifecycle, csi-driver-flow.) Diagnostics: extending_error needs an admin reset_status; the quota was rolled back.

4. Snapshot, share from snapshot, revert

sequenceDiagram
  autonumber
  participant C as client
  participant API as manila-api
  participant MQ as RabbitMQ
  participant SH as manila-share (source host)
  C->>API: POST /snapshots {"snapshot":{"share_id":…}}
  API-->>C: 202 creating
  API->>MQ: cast create_snapshot
  MQ->>SH: driver.create_snapshot → available
  C->>API: POST /shares {"share":{"snapshot_id":…}}
  Note over API: use_scheduler_creating_share_from_snapshot = False: host = source host, no scheduling
  API->>MQ: cast create_share_instance (manila-share.<source host>)
  MQ->>SH: driver.create_share_from_snapshot → available
  C->>API: POST /shares/{id}/action {"revert":{"snapshot_id":…}} (2.27, latest snapshot only)
  API->>MQ: cast revert_to_snapshot
  MQ->>SH: driver.revert_to_snapshot → available
  C->>API: DELETE /shares/{id}
  API-->>C: 403 "Share still has 1 dependent snapshots."

(scenario manilaclient-snapshots.) Diagnostics: a share from snapshot always lands on the source back end unless the option is enabled; revert fails with 409 when the snapshot is not the latest (manila/api/v2/shares.py:1355-1373).

5. Delete

sequenceDiagram
  autonumber
  participant C as client
  participant API as manila-api
  participant DB as MariaDB
  participant MQ as RabbitMQ
  participant SH as manila-share
  C->>API: DELETE /shares/{id}
  API->>API: checks: status, snapshots, backups, replicas, resource locks
  API->>DB: UPDATE share_instances status=deleting
  API->>MQ: cast delete_share_instance v1.27
  API-->>C: 202
  MQ->>SH: delete_share_instance
  SH->>SH: driver.update_access(deny all), driver.delete_share
  alt success
    SH->>DB: DELETE export locations, instance, share; quota release
    SH->>MQ: notification share.delete.end
  else driver error
    SH->>DB: status=error_deleting
  end
  C->>API: GET /shares/{id}
  API-->>C: 404

(scenarios manilaclient-share-lifecycle, csi-driver-flow.) Diagnostics: error_deleting → admin force_delete; with deferred deletion the share disappears at once and failures are retried by do_deferred_share_deletion.

6. Share transfer between projects

sequenceDiagram
  autonumber
  participant O as owner project
  participant N as new project
  participant API as manila-api
  participant MQ as RabbitMQ
  participant SH as manila-share
  O->>API: POST /share-transfers {"transfer":{"share_id":…}} (2.77)
  API-->>O: 202 {id, auth_key}; share status awaiting_transfer
  N->>API: POST /share-transfers/{id}/accept {"accept":{"auth_key":…,"clear_access_rules":true}}
  API->>MQ: call transfer_accept (manila-share, synchronous, manila/share/rpcapi.py:335)
  MQ->>SH: driver.transfer_accept, rules cleared
  API-->>N: 202; share project_id = new project

(scenario share-transfer.) Diagnostics: a transfer not accepted within transfer_retention_time (300 s) is removed by delete_expired_transfers and the share returns to available.

Source: reverse-spec-manila/04-scenarios_stable-2026.2.md. The _rewrite/ and _inventory/ files are not published on the site.