OpenStack Manila shared file systems

The network design must be settled with Neutron before the first share is created. A share network records the subnet and network segment that a share server will use to reach clients. With drivers that manage share servers, Manila creates server-side ports on those segments, so the choice of network type, segmentation, subnets, gateways and DNS is a decision the cloud's networking owners already control. Changing it later usually means rebuilding share servers and moving the storage path, which is disruptive once clients are mounted. Before go-live, review the segment and addressing plan with the Neutron owners, and confirm with your driver's documentation whether it uses share servers at all, since some back ends export shares without them.

Access rules are the control point for who can mount a share. Each rule grants a client identity or address range a level of access, such as read-only or read-write, and the rule is enforced by the share back end. The identity types that are available depend on the access protocol. Address-based rules are common for NFS, while user-based or certificate-style identities apply to other protocols, and the CephFS path uses its own identity model. Do not assume that every driver supports every combination of protocol, identity type and access level. Confirm, per driver, which network types and access protocols are supported, and write your access standard only against the combinations that the driver actually enforces.

The access model should follow project boundaries and identity. Manila resources belong to Keystone projects, so each share network, share and access rule should map to the team or tenant that owns the data. Address-based rules are only as strong as the network that assigns the addresses. If instances from one project can attach to a segment that another project uses, IP rules will not separate those tenants, and the segment design has to carry that boundary instead. Decide which Manila roles can create share networks and change access rules, and keep those roles with the owners of the data. Where users come from a corporate directory, use Keystone federation mapping so that group membership, not a manually maintained list, determines who receives those roles.

Verify the design before production use. In a non-production project, create a share network, confirm that the share server receives addresses on the intended segment, add a rule for one test client, and check that the client can mount the share while an unlisted client cannot. Record the approved rule set as the baseline for review. Plan for three recurring risks: rules left behind after instances are deleted, address ranges broader than the intended clients, and drift between Neutron security group settings and Manila access rules. Ask the driver vendor which of these controls the back end enforces itself, and ask any implementation partner to turn these checks into written acceptance criteria.

Migration starts with an inventory of what the standalone NFS or CIFS servers actually serve. For each export, record its path, protocol version, size and growth, owner, and the exact client list with its mount or mapping options. Include the hosts that mount it, the batch jobs, backup agents and applications that depend on it, and any direct references in configuration files. Clients that nobody remembers are a common source of cutover surprises, so check server access logs and active sessions over a representative period. The output should be a table an engineer can act on, with one row per export and one column for each client group.

Next, decide which exports become Manila shares and which stay where they are. Shares with one protocol, one network path and a clear set of clients are the easiest candidates. Map each export's protocol to a share type that your chosen back-end driver supports, and confirm that the client networks can reach the share network Manila will serve. Ask the driver's maintainers or documentation whether it can import an existing share into Manila in your target OpenStack release. If it cannot, the move becomes a data copy into a newly created share, which changes both the plan and its timing. The migration plan should be part of the written scope before work starts, with each export's disposition recorded.

Plan the copy window and cutover around the write pattern of each share. For read-mostly data, a bulk copy followed by a final incremental sync during a short freeze is a common approach. For active shares, agree a write freeze with the application owners, then verify file counts and checksums before clients switch to the new mount paths. Keep the source export read-only until the new share has passed verification so that rollback stays possible. Record who approves the cutover, how clients are repointed (DNS names, fstab or automount entries, or Windows drive mappings), and what conditions trigger a rollback. Ask for these steps to be itemized in any quote.

Finally, translate existing permissions into Manila access rules. NFS export options such as read-only access, client address lists and root squash must be re-expressed in the access types and levels that your driver and protocol support, then checked against the client set from the inventory. For CIFS shares, confirm how users and groups are identified in the directory the share relies on, and whether existing file ACLs survive the copy. Test each permission with a representative client from every group before cutover, including a denied case. Some options may not map directly, so document each exception and the owner who accepted it.

Kubernetes workloads reach Manila shares through the Manila Container Storage Interface (CSI) plugin, which maps PersistentVolumeClaims to Manila shares. Before the cluster is built, the team has to settle two things: the network path from worker nodes to the share network's export locations, and the identity the plugin uses to call the OpenStack APIs. Both decisions shape the storage class design and the access rules, so they belong in the design phase, not after the first volume fails to mount. The plugin runs controller components that talk to the Manila and Keystone APIs and node components that mount the share on each host, and each part needs a route to the services it depends on.

The first decision is which OpenStack project and credentials the plugin uses. A dedicated project, with a service identity or an application credential limited to that project, keeps share creation and deletion inside one set of quotas and one set of audit logs. Ask who owns that project, who approves quota changes and whether the cluster's share network is reachable from it. Store the credential as a Kubernetes Secret, restrict which service accounts and administrators can read it, and set a rotation procedure. Confirm in the plugin documentation how it handles expired or rotated application credentials, because a silent authentication failure can look like a storage outage.

The second decision is how each storage class maps to Manila. A storage class is effectively a policy: it selects the share type (which backend, performance tier and snapshot capability), the share network and the access rule the plugin applies. Most teams create one class per tier rather than one per application. Confirm which parameters the plugin accepts, which access types it supports for ReadWriteMany volumes and whether it can apply access rules based on node addresses or on identities in the backend. Node-address rules break when nodes are replaced, so plan the identity model before workloads depend on it. Also set the reclaim policy deliberately, because deleting a PersistentVolume may delete the underlying share and its data.

The third decision is how cluster upgrades affect the plugin version. The plugin, its CSI sidecar images and the Kubernetes minor version have to be compatible with each other, and a Kubernetes upgrade can make the installed plugin unsupported. Plan the plugin upgrade into the same change window as the cluster upgrade, test it on a non-production cluster that mounts real shares, and verify that existing volumes still attach and unmount afterward. OpenStack upgrades can also change Manila API behavior, so include them in the test matrix. Before planning any of this, confirm the plugin's supported Kubernetes and OpenStack versions in the vendor or project documentation, and record the versions you intend to run.