Train Series Release Notes


Bug Fixes

  • The API to import shares into manila could sometimes allow a share to be “managed” into manila multiple times via different export paths. This API could also incorrectly disallow a manage operation citing a new share in question was already managed. Both issues have now been fixed. See bug #1848608 and bug #1893718 for more details.

  • Fixed bug #1878993 that caused a failure on HTTPS connections within NetApp backend using python 3.7.

  • Fixed an issue while promoting back share replicas created using CIFS protocol. Please refer to the Launchpad bug #1879368 for more details.

  • Fixed bug #1886010 This bug caused glusterfs shares to still be readable/writable to connected clients while the share was deleted from manila.

  • An error with share group snapshot creation and deletion due to missing attributes has been fixed. See Launchpad bug 1888905 for more information.

  • Fixed bug #1894362 Fixed the problem of Couldn’t find the’gluster_used_vols’ error when deploying glusterfs driver multi-backend service and deleting share instance.

  • The NetApp cDOT driver now sets the required NFS options for clients running Windows operating systems with NFSv3 support.

  • Dell EMC Manila Driver: Fixes wrong capacity in pool_stat. bug 1890372 powermax manila return size in MB, bug 1890375 vnx manila return size in MB, bug 1890376 unity manila return size in bytes.


Upgrade Notes

  • The configuration option netapp_migration_cancel_timeout can be specified in the NetApp backend section to redefine the amount of time that the NetApp driver must attempt to wait on the asynchronous operation to cancel an ongoing migration. This option is set to 3600 seconds by default, which is sufficient time in most cases.

Bug Fixes

  • Dell EMC Unity Driver: Fixes bug 1841035 to avoid lots of error messages displayed in logs.

  • NetApp ONTAP share delete operation can fail sometimes when is triggered immediately after migration cancelation on a overloaded NetApp backend. Canceling an ongoing migration is an asynchronous operation on an ONTAP storage system. Now the NetApp driver checks if the asynchronous API has ended its operation before reporting migration cancelation success. If the operation of the asynchronous API did not end within the specified timeout, the migration cancel cancel operation will be considered unsuccessful. To do so, a new configuration option netapp_migration_cancel_timeout has been added.

  • Fixed the Generic driver to evict and kill any user processes accessing a share before attempting to extend or shrink a CIFS share.

  • A new user message has been added in case of share extensions failing asynchronously.

  • Fixed unneeded all ports list request to Neutron in service instance helper module on tearing down service subnet, Neutron can filter them by subnet_id itself.

  • NetApp ONTAP driver is now fixed to avoid the deletion of Cluster and Default ipspaces when deleting a share server. This issue was happening only when operating in driver_handles_share_servers enabled mode and creating shares using flat network type. See Launchpad bug 1880747 for more details.

  • Fixed bug #1882590 that caused an error on starting a NetApp backend when using the SVM scoped account.

  • Fixed launchpad bug #1885956 by ensuring that policy checks are enforced when looking up a share-type by name. This prevents a problem where shares could be stuck in CREATING status when a user attempts to create a share using the name of a private share-type to which the user lacks access.

  • The NetApp cDOT driver now validates the configuration of preferred domain controller(s) added in CIFS security service server setup. The mandatory option skip-config-validation was introduced to cifs-domain-preferred-dc-add with ONTAP 9.5.

  • The LVM driver no longer fails to delete shares, snapshots and access rules that are missing from storage. See Launchpad bug #1888915 for more details.


Bug Fixes

  • Fixed an issue with Unity driver fails to delete CIFS share if wrong access was set.


Bug Fixes

  • Fixed Launchpad bug 1699836 by preventing share type deletion when there are share group types associated with them.

  • NetApp cDOT driver is now fixed to remove the QoS Policy on the backend volume when a share is migrated from an extra-spec which had QoS defined to another extra-spec which has no QoS defined in it.

  • The NetApp cDOT driver is now fixed to honour the standard extra_specs during migration and manage/unmanage.

  • Fixed an issue in NetApp driver share replica periodic check that erroneously set a replica state to ‘error’. In this routine, a SnapMirror resync operation was being triggered while the replica data transfering is still in progress, receiving an error from the storage side. The driver now skips resync operation for all in progress SnapMirror relationship status.

  • Fixed an issue in NetApp driver when shrinking shares to a size smaller than the current used space. Now it will return a more appropriate error status called shrinking_possible_data_loss_error.

  • Launchpad bug 1869148 has been fixed. This bug could have affected environments where extension APIs were provided in compiled files rather than source code.

  • Reduces an increase of schedule time for non thin provisioned backends. On those backends, there is no need to calculate provisioned_capacity_gb, as it is not used during the scheduling. This calculation was not scaling properly on big environments as it implies many database queries.

  • Fixed the cleanup for private share types and share group types to include clearing out the database entries recording project specific access rules to these types. See Launchpad bug 1870751 for more details.

  • NetApp cDOT driver is now fixed to not create peer relationship between same share servers when handling share replica creation and promotion. This issue was happening when operating in driver_handles_share_servers enabled mode with backends configured with more than one pool. See Launchpad bug 1872243 for more details.

  • Fixed quota issue that made it impossible to create resources when the project had the quotas set to unlimited, and the user had a limited amount of quotas to use. Now, operations in the mentioned quota scenario are working properly. Please see Launchpad bug 1872872 for more details.

  • Updated the scheduler pool attributes provisioned_capacity_gb and allocated_capacity_gb to accommodate shares being created. This helps maintain an approximate tally of these attributes in between back end scheduler updates.

  • NetApp cDOT driver is now fixed to not trigger peer accept operation between share servers that belong to the same cluster, when handling share replica creation and promotion. This issue was happening when operating in driver_handles_share_servers enabled mode with multiple backends configured within the same cluster. See Launchpad bug 1873963 for more details.


New Features

  • A “no-op” interface driver ( has been introduced to work with drivers that create and manage lifecycle of share servers (driver_handles_share_servers=True) through service instance virtual machines using OpenStack Compute. This interface driver can be used when manila-share is running on a machine that has access to the administrator network used by Manila.

Security Issues

  • Closes a gap where a user can see the export locations for another user’s share if the uuid of the other share is leaked, stolen, or (improbably) guessed.

  • CVE-2020-9543: An issue with share network retrieval has been addressed in the API by scoping unprivileged access to project only. Please see launchpad bug #1861485 for more details.

Bug Fixes

  • Fixed Quota exceeded exception for snapshot creation. Consumed gigabytes now reports the snapshot gigabytes instead of share gigabytes usage.

  • Improved share list speed using lazy=’subquery’. The sqlalchemy models of Share and Share Instance relationships previously had lazy=’immediate’. This resulted in at least three extra queries when we queried for all share details.


Bug Fixes

  • Share type extra-specification share_backend_name is now ignored when creating share replicas. This ensures that backends in the same replication domain need not have the same value of share_backend_name. See launchpad bug #1634734 for details.

  • The NetApp ONTAP driver is now fixed to allow extension and shrinking of share replicas after they get promoted.

  • Fixed an issue with the Dell EMC Unity driver to work with a management IP configured in IPv6 format.

  • Fixed unexpected behavior when updating a share network’s neutron_net_id or neutron_subnet_id. Now, Manila does not allow updating a share network that does not contain a default subnet.



Added Manila share driver for Infortrend storage systems.

Add Inspur InStorage driver.

New Features

  • The name, description and/or share_type_access:is_public attributes of share types can be updated with API version 2.50 and beyond.

  • IPv6 support for CephFS Manila driver with NFS gateway.

  • For glusterfs_nfs driver, added share extend/shrink support.

  • The new Infortrend driver supports GS/GSe Family storage systems.

  • Add new Inspur InStorage driver, support share create, delete, extend, and access through NFS and CIFS protocol.

  • The NetApp driver now supports replication with driver_handles_share_servers set to True, in addition to the mode where the driver does not handle the creation and management of share servers. For replication to work across ONTAP clusters, clusters must be peered in advance.

  • Added revert to snapshot support for NexentaStor5 driver.

  • Added manage existing support for NexentaStor5 driver.

  • Rebrand from VMAX to PowerMax includes changing of tag names, directory structure, file names and documentation.

  • Added APIs with default policy set to ‘rule:default’ that allow the creation of share networks with multiple subnets. This gives the users the ability to create multiple subnets in a share network for different availability zones. Also, users will be able to delete and show existing subnets.

  • Updated the share server API to make possible to manage share servers in a specific subnet when the driver is operating in driver_handles_share_servers enabled mode.

  • Share servers are now associated with a single share network subnet, which pertain to a share network.

  • Dell EMC Unity Manila driver now supports the mode in which it does not itself create and destroy share servers (DHSS=False).

Upgrade Notes

  • The configuration option for the manila-data service, data_node_access_ip from the [DEFAULT] section is no longer supported. It was deprecated in favor of data_node_access_ips in the OpenStack Shared File Systems (manila) service release 6.0.0 (Queens).

  • The LVM driver configuration option lvm_share_export_ip is no longer supported. This option has been replaced by lvm_share_export_ips which accepts a comma-separated string of IP addresses of the host exporting the LVM shares (NFS/CIFS share server).

  • Added a new config option nexenta_ssl_cert_verify. This option defines whether the NexentaStor5 driver should check ssl certificate.

  • Added a new config option nexenta_rest_connect_timeout. This option specifies the time limit (in seconds), within which the connection to NexentaStor management REST API server must be established.

  • Added a new config option nexenta_rest_read_timeout. This option specifies the time limit (in seconds), within which NexentaStor management REST API server must send a response.

  • Added a new config option nexenta_rest_backoff_factor. This option specifies the backoff factor to apply between connection attempts to NexentaStor management REST API server.

  • Added a new config option nexenta_rest_retry_count. This option specifies the number of times to repeat NexentaStor management REST API call in case of connection errors and NexentaStor appliance EBUSY or ENOENT errors.

  • Added a new config option nexenta_dataset_record_size. This option specifies a suggested block size in for files in a filesystem’

    • emc_share_backend configuration option must be switched from vmax to powermax if using a newly rebranded PowerMax storage backend.

    • If using a PowerMax storage backend, deprecated options emc_nas_server_container, emc_nas_pool_names and emc_interface_ports can no longer be used. They must be replaced by powermax_server_container, powermax_share_data_pools and powermax_ethernet_ports respectively.

  • On upgrading to this release, all existing share networks will be updated to accommodate an availability zone assignment. Existing share networks will have their availability zone set to “empty” indicating that they are available across all storage availability zones known to manila.

Deprecation Notes

  • The following have been deprecated but will remain until the V release vmax_server_container is now powermax_server_container vmax_share_data_pools is now powermax_share_data_pools vmax_ethernet_ports is now powermax_ethernet_ports

Bug Fixes

  • The NetApp ONTAP driver is now fixed to unmount the original active share volume after one of its replica gets promoted.

  • The NetApp ONTAP driver is now fixed to set revert_to_snapshot_support to True or False depending upon SnapRestore License.

  • When the OpenStack administrator has a busy environment that contains many shares, the list operation with –limit parameter was taking too long to respond. This lag has now been fixed. See the launchpad bug 1795463 for more details.

  • When manila API is run behind a proxy webserver, the API service was parsing the major API version requested incorrectly, leading to incorrect responses. This behavior has now been fixed. See launchpad bug 1818081 for more details.

  • Update share networks with MTU before creating network allocations so that the first allocation in a share network is correct.

  • Fixed an issue with the NetApp driver failing during a rollback operation in the share server creation.

  • Launchpad bug 1822815 has been fixed. The user no longer gets an error if the list command has no rows when executing manila list –count True.

  • A share network cannot be provided while creating a share replica. Replicas will inherit the share’s share network if one exists.