manila — Interactions

Interactions — manila — branch stable/2026.2

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

Manila talks to five kinds of systems: its SQL database (every process), RabbitMQ (RPC between the four processes, and notifications), Keystone (tokens, through keystonemiddleware), other OpenStack services (Nova, Neutron, Cinder, Glance, Barbican — only for some drivers and features), and the storage back ends (driver-specific protocols: SSH, REST, librados…). The RPC frames below were recorded by the client scenarios ([_rewrite/rpc-frames_stable-2026.2.json](_rewrite/rpc-frames_stable-2026.2.json), 247 frames).

RabbitMQ

Topology

oslo.messaging, driver selected by [DEFAULT]/transport_url. Manila never calls rpc.set_defaults (manila/rpc.py:82-83 is unused), so the **control exchange is the oslo.messaging default openstack**.

Each manila-share process runs one service per back end of [DEFAULT]/enabled_share_backends, with host <[DEFAULT]/host>@<backend> (manila/cmd/share.py:44-51); the RPC server listens on manila-share.<host>@<backend> (manila/service.py:160-163). The share-side RPC client strips the pool part of a host (host@backend#pool → host@backend) before sending (manila/share/rpcapi.py:308).

Serialisation: RequestContextSerializer wraps the request context (keys auth_token, user_id, project_id, roles, is_admin, request_id, read_deleted, service_catalog, quota_class, remote_address, timestamp… — 25 keys recorded) and passes arguments through the oslo JSON codec; database models are converted to dictionaries by jsonutils.to_primitive (manila/rpc.py:104-140). There are no versioned objects: the receiving manager gets plain dicts and usually re-reads the rows from the database.

RPC methods

RPC_API_VERSION: share 1.30 (manila/share/manager.py:290, client cap manila/share/rpcapi.py:102), scheduler 1.11 (manila/scheduler/manager.py:71, manila/scheduler/rpcapi.py:49), data 1.1 (manila/data/manager.py:118, manila/data/rpcapi.py:48). "(observed)" marks the methods seen in the recorded frames.

The share-side methods not listed with "(observed)" (snapshot access, replicas' snapshots, share server migration, network updates, backups to the driver…) follow the same pattern: a cast to manila-share.<host>@<backend> with ids, the manager re-reading the rows. The only synchronous calls are get_pools (scheduler), connection_get_info, migration_get_progress, share_server_migration_check|get_progress, get_share_server_network_info, check_update_share_server_network_allocations, transfer_accept (manila/share/rpcapi.py:335) and the data service's data_copy_*: they block the API worker up to [DEFAULT]/rpc_response_timeout.

Notifications

Sent only when [oslo_messaging_notifications]/driver is set (manila/utils.py:597-604), at INFO priority unless stated, with publisher_id = "<service>.<host>" (manila/rpc.py:165-169).

Sample frames

update_access, cast from manila-api to the share service of the share's host, as recorded (the oslo.messaging envelope {"oslo.version": "2.0", "oslo.message": "<JSON below as a string>"} is added by the driver):

{
  "method": "update_access",
  "args": {"share_instance_id": "fa903622-de80-4782-b693-7e7505bd6d46"},
  "version": "1.14",
  "_unique_id": "…", "_context_user_id": "de5e0000000000000000000000005e00",
  "_context_project_id": "de0000000000000000000000000000de", "_context_roles": ["member", "reader"],
  "_context_request_id": "req-…", "_context_auth_token": "…", "_context_is_admin": false,
  "_context_read_deleted": "no", "_context_service_catalog": null
}

routing key manila-share.node-1@alpha, exchange openstack.

update_service_capabilities, fanout cast from each manila-share every periodic_interval (60 s) to manila-scheduler_fanout (manila/scheduler/rpcapi.py:67-76): service_name: "share", host: "node-1@alpha", timestamp, and capabilities = the driver's _stats (manila/share/driver.py:1344-1406): share_backend_name, driver_handles_share_servers, vendor_name, driver_version, storage_protocol, total_capacity_gb, free_capacity_gb, reserved_percentage, reserved_snapshot_percentage, reserved_share_extend_percentage, qos, pools: [{pool_name, total_capacity_gb, free_capacity_gb, …}], snapshot_support, create_share_from_snapshot_support, revert_to_snapshot_support, mount_snapshot_support, replication_domain, replication_type, filter_function, goodness_function, ipv4_support, ipv6_support, share_group_stats… The full recorded payload is in rpc-frames_stable-2026.2.json.

Database

Tables

SQLAlchemy models in manila/db/sqlalchemy/models.py, schema by alembic migrations (manila/db/migrations/alembic/versions/, head afc3b5e1f406, 76 revisions). Accessed by every process through manila/db/sqlalchemy/api.py (oslo.db enginefacade). 53 tables ([_rewrite/schema-sqlite-migrated_stable-2026.2.sql](_rewrite/schema-sqlite-migrated_stable-2026.2.sql)); almost all are soft-deleted (deleted, deleted_at).

Notable transactions

• Quota reservation (manila/db/sqlalchemy/api.py:1205-1475): quota_reserve locks the user's and project's usage rows with SELECT … FOR UPDATE (manila/db/sqlalchemy/api.py:1158-1184), refreshes them if until_refresh / max_age say so, checks the deltas against the limits and inserts reservations rows (expire after reservation_expire, 86400 s, manila/quota.py:84); reservation_commit / reservation_rollback (manila/db/sqlalchemy/api.py:1478-1530) move the reserved amounts to in_use or back, also under FOR UPDATE (manila/db/sqlalchemy/api.py:1472). These functions retry deadlocks 5 times (@oslo_db_api.wrap_db_retry, manila/db/sqlalchemy/api.py:1233).
• Share create: share_create + share_instance_create are two transactions; the quota commit is between them (manila/share/api.py:516-528), with a compensating share_delete + rollback on failure.
• Access rules: the state changes of share_instance_access_map are serialised per share instance by a process-local lock utils.synchronized("locked_access_rules_operation_by_share_instance_<id>", external=True) (manila/share/access.py:28-55) — an oslo.concurrency file lock in [oslo_concurrency]/lock_path, so only processes on the same host are serialised.
• Distributed locks: replica and some share operations use tooz (manila/coordination.py:42-160, [coordination]/backend_url, default file://$state_path) through @coordination.synchronized (manila/share/manager.py:226, manila/share/manager.py:246). With the default file backend these locks are host-local: running two manila-share services for the same back end on two hosts needs a real tooz backend (etcd, Redis…).

Outbound REST calls

All use keystoneauth sessions built from a configuration group (manila/common/client_auth.py:34-99); only admin clients exist: a non-admin context raises "Client (<group>) is not flagged as admin" (manila/common/client_auth.py:87-96). None is used on the path of a DHSS=False back end except Barbican for encryption.

Other (binaries, files)

• rootwrap / privsep: drivers run storage commands through sudo manila-rootwrap (manila/utils.py:88, filters etc/manila/rootwrap.d/share.filters) or SSH to the back end (manila/utils.py SSHPool).
• manila-data mounts the source and destination exports locally (mount through rootwrap) and copies files for host-assisted migration and data-manager backups (manila/data/helper.py, manila/data/utils.py).
• Driver protocols: one per back end (NetApp ONTAP REST/ZAPI, CephFS via librados/ceph mgr, LVM/ZFS via shell, Generic via SSH into a VM…). Not specified here: OpenKeel replaces them by a CSI-backed driver (07 § 3).

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