Chapter 6. Configuring the Shared File Systems service (manila)

With the Shared File Systems service (manila), you can provision shared file systems that multiple cloud user instances, bare-metal nodes, or containers can consume. Cloud administrators create share types to prepare the share service and enable end users to create and manage shares. You use the Shared File Systems service command-line client to manage shared file systems.

Prerequisites

  • An end user requires at least one share type to use the Shared File Systems service.
  • For back ends where driver_handles_share_servers=false, a cloud administrator configures the requisite networking in advance rather than dynamically in the shared file system back end.
  • For a CephFS-NFS back end, a cloud administrator deploys Red Hat OpenStack Platform (RHOSP) director with isolated networks and environment arguments and a custom network_data file to create an isolated StorageNFS network for NFS exports. After deployment, before the overcloud is used, the administrator creates a corresponding Networking service (neutron) StorageNFS shared provider network that maps to the isolated StorageNFS network of the data center.
  • For a Compute instance to connect to this shared provider network, the user must add an additional neutron port.

6.1. Configuring Shared File Systems service back ends

When cloud administrators use Red Hat OpenStack Platform (RHOSP) director to deploy the Shared File Systems service (manila), they can choose one or more supported back ends, such as native CephFS, CephFS-NFS, NetApp, Dell EMC Unity, and others.

For more information about native CephFS and CephFS-NFS, see Deploying Red Hat Ceph Storage and Red Hat OpenStack Platform together with director.

For a complete list of supported back-end appliances and drivers, see the Manila section of the Red Hat Knowledge Article, Component, Plug-In, and Driver Support in Red Hat OpenStack Platform.

6.1.1. Configuring multiple back ends

A back end is a storage system or technology that is paired with the Shared File Systems service (manila) driver to export file systems. The Shared File Systems service requires at least one back end to operate. In many cases, one back end is sufficient. However, you can also use multiple back ends in a single Shared File Systems service installation.

Important

Red Hat OpenStack Platform (RHOSP) does not support multiple instances of the same back end to a Shared File Systems service deployment. For example, you cannot add two Red Hat Ceph Storage clusters as back ends within the same deployment. CephFS native and CephFS-NFS are considered one back end with different protocols.

The scheduler for the Shared File Systems service determines the destination back end for share creation requests. A single back end in the Shared File Systems service can expose multiple storage pools.

When you configure multiple back ends, the scheduler chooses one storage pool to create a resource from all the pools exposed by all configured back ends. This process is abstracted from the end user. End users see only the capabilities that are exposed by the cloud administrator.

6.1.2. Deploying multiple back ends

By default, the environment file you use to deploy the Shared File Systems service (manila) has a single back end. Use the following example procedure to deploy two back ends, a CephFS-NFS back end and a NetApp back end.

Important

When you add multiple storage back ends from the same vendor to your deployment, configure one back end by using the this procedure. Configure the other back ends as custom back ends. For more information, see Configuring custom back ends and Deploying custom back ends.

Prerequisites

  • At least two back ends.
  • When you use a back-end driver from a storage vendor that requires external software components, you must override the standard container image for the Shared File Systems service during deployment. You can find custom container images, for example, the Dell EMC Unity container image for a Dell EMC Unity storage system, at Red Hat Ecosystem Catalog.

Procedure

  1. Create a storage customization YAML file to provide any values or overrides that suit your environment: 

    $ vi /home/stack/templates/<multiple_backends>.yaml
    • Replace <multiple_backends> with the name of your file.

  2. Configure the storage customization YAML file to include any overrides and enable multiple back ends: 

    parameter_defaults:
  ManilaEnabledShareProtocols:
    - NFS
  ManilaNetappLogin: '<login_name>'
  ManilaNetappPassword: '<password>'
  ManilaNetappServerHostname: '<netapp-hostname>'
  ManilaNetappVserver: ‘<netapp-vserver>’
  ManilaNetappDriverHandlesShareServers: 'false'
    • Replace the values in angle brackets <> with the correct values for your YAML file.
  3. Log in to the undercloud host as the stack user.

  4. Source the stackrc undercloud credentials file: 

    $ source ~/stackrc

  5. Add the the storage customization YAML file to the stack with your other environment files and deploy the overcloud. This example configuration enables the Shared File Systems service with a NetApp back end and a CephFS-NFS back end. 

    $ openstack overcloud deploy \
  --timeout 100 \
  --stack overcloud \
  --templates /usr/share/openstack-tripleo-heat-templates \
  -n /usr/share/openstack-tripleo-heat-templates/network_data_ganesha.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
  -r /home/stack/templates/roles/roles_data.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml \
  -e /home/stack/templates/storage_customizations.yaml \
  ...

Additional resources

6.1.3. Confirming deployment of multiple back ends

Use the manila service-list command to verify that your Shared File Systems service (manila) back ends deployed successfully. If you use a health check on multiple back ends, a ping test returns a response even if one of the back ends is unresponsive, so this is not a reliable way to verify your deployment.

Procedure

  1. Source the overcloud credentials file: 

    $ source ~/<credentials_file>
    • Replace <credentials_file> with the name of your credentials file, for example, overcloudrc.

  2. Confirm the list of Shared File Systems service back ends: 

    $ manila service-list

+----+--------+--------+------+---------+-------+----------------------------+
| Id | Binary | Host | Zone | Status | State | Updated_at |
+----+--------+--------+------+---------+-------+----------------------------+
| 2 | manila-scheduler | hostgroup | nova | enabled | up | 2021-03-24T16:49:09.000000 |
| 5 | manila-share | hostgroup@cephfs | nova | enabled | up | 2021-03-24T16:49:12.000000 |
| 8 | manila-share | hostgroup@tripleo_netapp | nova | enabled | up | 2021-03-24T16:49:06.000000 |

    The status of each successfully deployed back end shows enabled and the state shows up.

6.1.4. Configuring custom back ends

You can deploy custom storage back ends that do not have their corresponding implementation in the Red Hat OpenStack Platform (RHOSP) director installer.

When you add multiple storage back ends from the same vendor to your deployment, configure one back end by using the procedure in Deploying multiple back ends. Configure the other back ends as custom back ends.

When you deploy a custom back end, check if the storage back-end vendor requires a custom container image instead of the standard container image for the Shared File Systems service (manila). You can find custom container images at Red Hat Ecosystem Catalog.

Procedure

  1. Create a storage customization YAML file to provide any values or overrides that suit your environment: 

    $ vi /home/stack/templates/<custom_backend_data>.yaml
    • Replace <custom_backend_data> with the name of your file.

  2. Configure the storage customization YAML file with the container image required by the Shared File Systems service: 

    parameter_defaults:
  ContainerManilaShareImage: <custom_container_image_url>
    • Replace <custom_container_image_url> with the URL of your custom container image.

  3. Use the ControllerExtraConfig parameter to configure the back ends required by the Shared File Systems service. This parameter ensures that the configuration is applied to all Controller nodes: 

    parameter_defaults:
  ...
  ControllerExtraConfig:
    manila::config::manila_config:
      <backend_name>/<parameter>:
        value: '<parameter_value>'
    • Replace <backend_name> with the name of your custom back end.
    • Replace <parameter> with the name of the parameter that you want to configure for this back end, for example, netapp_server_hostname or netapp_password.

    • Replace <parameter_value> with the value that you want to set for the parameter, for example, 203.0.113.20 or admin_password.

      Note

      If you use a custom role, use [role_name]ExtraConfig instead of the ControllerExtraConfig parameter. Replace [role_name] with the name of your custom role.

6.1.5. Deploying custom back ends

When you have configured custom storage back ends for your Red Hat OpenStack Platform (RHOSP) deployment as described in Configuring custom back ends, you can add them to your deployment.

Procedure

  1. Create a storage customization YAML file to provide any values or overrides that suit your environment: 

    $ vi /home/stack/templates/<manila_enabled_share_backends>.yaml
    • Replace <manila_enabled_share_backends> with the name of your file.

  2. Configure the storage customization YAML file to add the custom back end to the list of enabled share back ends: 

    parameter_defaults:
  ControllerExtraConfig:
    manila_user_enabled_backends:
      - '<backend_name>'
    • Replace <backend_name> with the name of your your custom back end.

  3. Add the the storage customization YAML file to the stack with your other environment files and deploy the overcloud: 

    $ openstack overcloud deploy --templates \
-e [your environment files] \
  -e /home/stack/templates/<manila_enabled_share_backends>.yaml

6.1.6. Deploying availability zones for back ends

You can create availability zones (AZs) to group cloud infrastructure and services logically for cloud users. You can map the AZs to failure domains and compute resources for high availability, fault tolerance, and resource scheduling. For example, you can create an AZ of Compute nodes that have specific hardware that cloud users can specify when they create an instance that requires that hardware.

A share is always associated with an AZ. If you do not set the AZ parameters when you create a share, the Shared File Systems service (manila) associates the share with a default AZ called nova. You use the ManilaXXXAvailabilityZone parameters, where XXX is associated with a specific back end, to configure different AZs for Shared File Systems service back ends. For more information about AZs, see Creating and managing host aggregates in Configuring the Compute service for instance creation.

IMPORTANT
If you change the AZ parameters for existing shares, these shares continue to be associated with the original AZ while their back end is mapped to the new AZ. There is currently no way to reconcile a conflict between the original AZ and the newly mapped AZ when you change the AZ parameters on existing shares.

Procedure

  1. Add the following parameters to your Shared File Systems service environment file to create two AZs: 

    parameter_defaults:
 ManilaXXXAvailabilityZone: zone1
 ManilaYYYAvailabilityZone: zone2

    • Replace XXX and YYY with supported back-end values, such as: 

      ManilaCephFSAvailabilityZone
ManilaNetAppAvailabilityZone

      The following example deploys two back ends where CephFS is zone 1 and NetApp is zone 2: 

      parameter_defaults:
 ManilaCephFSAvailabilityZone: zone1
 ManilaNetAppAvailabilityZone: zone2
      NOTE
      Search the /usr/share/openstack-tripleo-heat-templates/deployment/manila/ directory for the heat template that is associated with your back end for the correct back-end value.
  2. Log in to the undercloud host as the stack user.

  3. Source the stackrc undercloud credentials file: 

    $ source ~/stackrc

  4. Add your updated Shared File Systems service environment file to the stack with your other environment files and deploy the overcloud: 

    $ openstack overcloud deploy --templates \
  -e [your environment files] \
  -e /home/stack/templates/<updated_environment_file>.yaml
  5. Post deployment, use the availability_zones share type extra specification to limit share types to one or more AZs. Cloud users can create a share directly in an AZ as long as the share type does not restrict them.

Additional resources

6.1.7. Changing the allowed NAS protocols

You can use the Shared File Systems service (manila) to export shares in the NFS, CephFS, or CIFS network attached storage (NAS) protocols. By default, the Shared File Systems service enables all of the NAS protocols supported by the back ends in a deployment.

As a Red Hat OpenStack Platform (RHOSP) administrator, you can change the ManilaEnabledShareProtocols parameter and list only the protocols that you want to allow in your cloud. For example, if back ends in your deployment support both NFS and CIFS, you can change the default value and enable only one protocol.

Not all storage back-end drivers support the CIFS protocol. For information about which certified storage systems support CIFS, see the Red Hat Ecosystem Catalog. For information about configuring the service through RHOSP director, see the vendor storage documentation.

Procedure

  1. Source the overcloud credentials file: 

    $ source ~/<credentials_file>
    • Replace <credentials_file> with the name of your credentials file, for example, overcloudrc.

  2. Create a storage customization YAML file to provide any values or overrides that suit your environment: 

    $ vi /home/stack/templates/<share_protocols>.yaml
    • Replace <share_protocols> with the name of your file.

  3. Configure the ManilaEnabledShareProtocols parameter with the NAS protocols you want to enable: 

    parameter_defaults:
  ManilaEnabledShareProtocols:
    - NFS
    - CEPHFS

  4. Add your storage customization YAML file to the stack with your other environment files and deploy the overcloud: 

    $ openstack overcloud deploy --templates \
-e [your environment files] \
  -e /home/stack/templates/<share_protocols>.yaml
    Note

    The deployment does not validate the settings. The NAS protocols that you assign must be supported by the back ends in your Shared File Systems service deployment.

6.1.8. Viewing back-end capabilities

The scheduler component of the Shared File Systems service (manila) makes intelligent placement decisions based on several factors such as capacity, provisioning configuration, placement hints, and the capabilities that the back-end storage system driver detects and exposes.

Procedure

  • Run the following command to view the available capabilities: 

    $ manila pool-list --detail
+------------------------------------+----------------------------+
| Property                           | Value                      |
+------------------------------------+----------------------------+
| name                               | hostgroup@cephfs#cephfs    |
| pool_name                          | cephfs                     |
| total_capacity_gb                  | 1978                       |
| free_capacity_gb                   | 1812                       |
...
| driver_handles_share_servers       | False                      |
| snapshot_support                   | True                       |
| create_share_from_snapshot_support | False                      |
| revert_to_snapshot_support         | False                      |
| mount_snapshot_support             | False                      |
...
+------------------------------------+----------------------------+
+------------------------------------+-----------------------------------+
| Property                           | Value                             |
+------------------------------------+-----------------------------------+
| name                               | hostgroup@tripleo_netapp#aggr1_n1 |
| pool_name                          | aggr1_n1                          |
| total_capacity_gb                  | 6342.1                            |
| free_capacity_gb                   | 6161.99                           |
...
| driver_handles_share_servers       | False                             |
| mount_snapshot_support             | False                             |
| replication_type                   | None                              |
| replication_domain                 | None                              |
| sg_consistent_snapshot_support     | host                              |
| ipv4_support                       | True                              |
| ipv6_support                       | False                             |
+------------------------------------+-----------------------------------+
+------------------------------------+-----------------------------------+
| Property                           | Value                             |
+------------------------------------+-----------------------------------+
| name                               | hostgroup@tripleo_netapp#aggr1_n2 |
| pool_name                          | aggr1_n2                          |
| total_capacity_gb                  | 6342.1                            |
| free_capacity_gb                   | 6209.26                           |
...
| snapshot_support                   | True                              |
| create_share_from_snapshot_support | True                              |
| revert_to_snapshot_support         | True                              |
| driver_handles_share_servers       | False                             |
| mount_snapshot_support             | False                             |
| replication_type                   | None                              |
| replication_domain                 | None                              |
| sg_consistent_snapshot_support     | host                              |
| ipv4_support                       | True                              |
| ipv6_support                       | False                             |
+------------------------------------+-----------------------------------+

Related information

To influence placement decisions, as an administrator, you can use share types and extra specifications. For more information about share types, see Creating share types.

6.2. Creating share types

Cloud administrators can create share types to define the type of service that the Shared File Systems service (manila) scheduler uses to make scheduling decisions and that drivers use to control share creation.

Share types include a description and extra specifications, for example, driver_handles_share_servers and snapshot_support, to filter back ends. Red Hat OpenStack Platform (RHOSP) director configures the Shared File Systems service with a default share type named default, but director does not create the share type.

Cloud users require at least one share type to use the Shared File Systems service, and users can only create shares that match the available share types.

By default, share types are public, which means they are available to all cloud projects. However, you can create private share types for use within specific projects.

In the following example procedure, you use the driver_handles_share_servers parameter (DHSS), which you can set to true or false:

  • For CephFS-NFS and native CephFS, you set DHSS to false.
  • For other back ends, you can set DHSS to true or false. You set the DHSS value to match the value of the Manila<backend>DriverHandlesShareServers parameter in your storage customization environment file. For example, if you use a NetApp back end, this parameter is ManilaNetappDriverHandlesShareServers.

Procedure

  1. After you deploy the overcloud, run the following command to create a share type: 

    $ manila type-create default <driver_handles_share_servers>
    • Replace <driver_handles_share_servers> with true or false.

  2. Add specifications to the default share type or create additional share types to use with different back ends. In this example, configure the default share type to select a CephFS back end and an additional share type that uses a NetApp driver_handles_share_servers=true back end: 

    $ manila type-create default false \
  --extra-specs share_backend_name='cephfs'
$ manila type-create netapp true \
  --extra-specs share_backend_name='tripleo_netapp'

Additional resources

6.3. Comparing common capabilities of share types

Share types define the common capabilities of shares. Review the common capabilities of share types to understand what you can do with your shares.

Table 6.1. Capabilities of share types

CapabilityValuesDescription

driver_handles_share_servers

true or false

Grants permission to use share networks to create shares.

snapshot_support

true or false

Grants permission to create snapshots of shares.

create_share_from_snapshot_support

true or false

Grants permission to create clones of share snapshots.

revert_to_snapshot_support

true or false

Grants permission to revert your shares to the most recent snapshot.

mount_snapshot_support

true or false

Grants permission to export and mount your snapshots.

replication_type

dr

Grants permission to create replicas for disaster recovery. Only one active export is allowed at a time.

readable

Grants permission to create read-only replicas. Only one writable, active export is allowed at a time.

writable

Grants permission to create read/write replicas. Any number of active exports are allowed at a time per share.

availability_zones

a list of one or more availability zones

Grants permission to create shares only on the availability zones listed.

6.4. Adding and removing shares by using manage/unmanage

Cloud administrators can manage file shares that already exist in storage through the Shared File Systems service (manila) manage/unmanage feature. You can perform operations on managed shares, such as granting access, mounting, and resizing, in the same way that you perform these operations on Shared File Systems service shares.

You can manage the lifecycle of shares that have the driver_handles_share_servers parameter (DHSS) set to true and shares that have DHSS set to false. To manage DHSS=true shares, the cloud administrator must also manage the share server that contains the share.

When you unmanage a share, you remove the share from the management of the Shared File Systems service without deleting the share. If shares have dependent snapshots or share replicas, you can only remove the shares from the Shared File Systems service when the snapshots or share replicas have been removed.

Limitations

  • The driver must support manage/unmanage functionality.
  • The manage/unmanage feature does not support native CephFS or CephFS-NFS back ends. You can remove CephFS shares from the management of the Shared File Systems service. However, you cannot bring existing CephFS shares under the management of the Shared File Systems service.
  • When you bring a share under the management of the Shared File Systems service, existing clients are disconnected. When you remove a share from the management of the Shared File Systems service, existing clients remain connected.

Procedure

  1. Manage a share: 

    manila manage
--name <name>
--description <description>
--share_type <share-type>
--driver_options [<key=value> [<key=value> ...]]
                    [--public] [--share_server_id <share-server-id>] \
                    [--wait] <service_host> <protocol> <export_path>
    • Replace the values in angle brackets <> with the correct values for your environment.

  2. Verify that the share is available: 

    $ manila show <name>

  3. Unmanage a share: 

    manila unmanage [--wait] <name>

6.5. Planning networking for shared file systems

Plan the networking on your cloud to ensure that end-user clients can connect their shares to workloads that run on Red Hat OpenStack Platform (RHOSP) virtual machines, bare-metal servers, and containers.

Depending on the level of security and isolation required for cloud users, you can set the driver_handles_share_servers parameter (DHSS) to true or false.

DHSS=true

If you set the DHSS parameter to true, you can use the Shared File Systems service (manila) to export shares to end-user defined share networks with isolated share servers. Users can provision their workloads on self-service share networks to ensure that isolated NAS file servers on dedicated network segments export their shares.

As a cloud administrator, you must ensure that the physical network to which you map the isolated networks extends to your storage infrastructure. You must also ensure that the storage system that you are using supports network segments. Storage systems, such as NetApp ONTAP and Dell EMC PowerMax, Unity, and VNX, do not support virtual overlay segmentation styles such as GENEVE or VXLAN.

As an alternative to overlay networking, you can do any of the following:

  • Use VLAN networking for your project networks.
  • Allow VLAN segments on shared provider networks.
  • Provide access to a pre-existing segmented network that is already connected to your storage system.

DHSS=false

If you set the DHSS parameter to false, cloud users cannot create shares on their own share networks. They must connect their clients to the network configured by the cloud administrator.

As a cloud administrator, you can create a dedicated shared storage network through director. For example, when you deploy the native CephFS back end with standard director templates, you generate a shared provider network called Storage. When you deploy CephFS through the NFS back end, you generate a shared provider network called StorageNFS. Cloud users must connect their clients to the shared storage network to access their shares.

Not all shared file system storage drivers support both DHSS=true and DHSS=false. Both DHSS=true and DHSS=false ensure data path multi-tenancy isolation. However, if you require network path multi-tenancy isolation for tenant workloads as part of a self-service model, you must deploy the Shared File Systems service with back ends that support DHSS=true.

For information about network connectivity to the share, see Section 6.6, “Ensuring network connectivity to the share”.

6.6. Ensuring network connectivity to the share

To connect to a file share, clients must have network connectivity to one or more of the export locations for that share.

When cloud administrators set the driver_handles_share_servers parameter (DHSS) for a share type to true, cloud users can create a share network with the details of a network to which the Compute instance attaches. Cloud users can then reference the share network when creating shares.

When cloud administrators set the DHSS parameter for a share type to false, cloud users must connect their Compute instance to the shared storage network that the cloud administrator has configured. For more information about how to configure and validate network connectivity to a shared network, see Section 7.5, “Connecting to a shared network to access shares”.

6.7. Changing the default quotas in the Shared File Systems service

To prevent system capacities from being exhausted without notification, cloud administrators can configure quotas. Quotas are operational limits. The Shared File Systems service (manila) enforces some sensible limits by default. These limits are called default quotas. Cloud administrators can override default quotas so that individual projects have different consumption limits.

6.7.1. Updating quotas for projects, users, and share types

As a cloud administrator, you can list the quotas for a project or user by using the manila quota-show command.

You can update quotas for all users in a project, or a specific project user, or a share type used by the project users. You can update the following quotas for the target you choose:

  • shares: Number of shares that you can create.
  • snapshots: Number of snapshots that you can create.
  • gigabytes: Total size in GB that you can allocate for all shares.
  • snapshot-gigabytes: Total size in GB that you can allocate for all snapshots of shares.
  • share-networks: Total number of share networks that you can create.
  • share_groups: Total number of share groups that you can create.
  • share_group_snapshots: Total number of share group snapshots that you can create.
  • share-replicas: Total number of share replicas that you can create.
  • replica-gigabytes: Total size in GB that you can allocate across all share replicas.
Note

You can only specify share-type quotas at the project level. You cannot set share-type quotas for specific project users.

Important

In the following procedures, enter the values carefully. The Shared File Systems service does not detect or report incorrect values.

Procedure

  1. You can use the following commands to view quotas. If you include the --user option, you can view the quota for a specific user in the specified project. If you omit the --user option, you can view the quotas that apply to all users for the specified project.

    Similarly, if you include the optional --share-type, you can view the quota for a specific share type as it relates to the project. The --user and --share-type options are mutually exclusive. 

    $ manila quota-show

    • Example for a project: 

      $ manila quota-show \
  --project af2838436f3f4cf6896399dd97c4c050
+-----------------------+----------------------------------+
| Property              | Value                            |
+-----------------------+----------------------------------+
| gigabytes             | 1000                             |
| id                    | af2838436f3f4cf6896399dd97c4c050 |
| replica_gigabytes     | 1000                             |
| share_group_snapshots | 50                               |
| share_groups          | 49                               |
| share_networks        | 10                               |
| share_replicas        | 100                              |
| shares                | 50                               |
| snapshot_gigabytes    | 1000                             |
| snapshots             | 50                               |
+-----------------------+----------------------------------+

    • Example for a project user: 

      $ manila quota-show \
  --project af2838436f3f4cf6896399dd97c4c050 \
  --user 81ebb491dd0e4c2aae0775dd564e76d1
+-----------------------+----------------------------------+
| Property              | Value                            |
+-----------------------+----------------------------------+
| gigabytes             | 500                              |
| id                    | af2838436f3f4cf6896399dd97c4c050 |
| replica_gigabytes     | 1000                             |
| share_group_snapshots | 50                               |
| share_groups          | 49                               |
| share_networks        | 10                               |
| share_replicas        | 100                              |
| shares                | 25                               |
| snapshot_gigabytes    | 1000                             |
| snapshots             | 50                               |
+-----------------------+----------------------------------+

    • Example for a project for a specific share type: 

      $ manila quota-show \
  --project af2838436f3f4cf6896399dd97c4c050 \
  --share-type dhss_false
+---------------------+----------------------------------+
| Property            | Value                            |
+---------------------+----------------------------------+
| gigabytes           | 1000                             |
| id                  | af2838436f3f4cf6896399dd97c4c050 |
| replica_gigabytes   | 1000                             |
| share_replicas      | 100                              |
| shares              | 15                               |
| snapshot_gigabytes  | 1000                             |
| snapshots           | 50                               |
+---------------------+----------------------------------+

  2. Use the manila quota-update command to update the quotas. You can update quotas for all project users, a specific project user, or a share type in a project:

    • Update quotas for all users in a project: 

      $ manila quota-update <id> \
  [--shares <share_quota> \
  --gigabytes <share_gigabytes_quota> \
  …]

      Replace <id> with the project ID. This value must be the project ID, not the project name.

    • Update quotas for a specific user in a project: 

      $ manila quota-update <id> \
  --user <user_id> \
  [--shares <new_share_quota> \
  --gigabytes <new_share_gigabytes_quota> \
  …]
      • Replace <id> with the project ID. This value must be the project ID, not the project name.
      • Replace <user_id> with the user ID. The value must be the user ID, not the user name.

    • Update quotas for all users who use a specific share type: 

      $ manila quota-update <id> \
  --share-type <share_type> \
  [--shares <new_share_quota>30
  --gigabytes <new-share_gigabytes_quota> \
  …]
      • Replace <id> with the project ID. This value must be the project ID, not the project name.
      • Replace <share_type> with the name or ID of the share type that you want to apply the quota to.

Verification

  • The quota-update command does not produce any output. Use the quota-show command to verify that a quota was successfully updated.

6.7.2. Resetting quotas for projects, users, and share types

You can remove quota overrides to return quotas to their default values. The target entity is restricted by the default quota that applies to all projects with no overrides.

Procedure

  • Use the manila quota-delete command to return quotas to default values. You can return quotas to default values for all project users, a specific project user, or a share type in a project:

    • Reset project quotas: 

      $ manila quota-delete --project <id>

      Replace <id> with the project ID. This value must be the project ID, not the project name.

    • Reset quotas for a specific user: 

      $ manila quota-delete --project <id> --user <user_id>
      • Replace <id> with the project ID. This value must be the project ID, not the project name.
      • Replace <user_id> with the user ID. The value must be the user ID, not the user name.

    • Reset quotas for a share type used by project users: 

      $ manila quota-delete --project <id> --share-type <share_type>
      • Replace <id> with the project ID. This value must be the project ID, not the project name.
      • Replace <share_type> with the name or ID of the share type the quota must be reset for.

Verification

  1. The quota-delete command does not produce any output. Use the quota-show command to verify whether a quota was successfully reset.

  2. List the default quotas for all projects. Default quotas apply to projects that have no overrides. 

    $ manila quota-class-show default

6.7.3. Updating the default quota values for Shared File Systems service projects

As a cloud administrator, you can update default quotas that apply to all projects that do not already have quota overrides.

Procedure

  1. View the usage statement of the manila quota-class-update command: 

    $ manila help quota-class-update
usage: manila quota-class-update [--shares <shares>] [--snapshots <snapshots>]
                                 [--gigabytes <gigabytes>]
                                 [--snapshot-gigabytes <snapshot_gigabytes>]
                                 [--share-networks <share_networks>]
                                 [--share-replicas <share_replicas>]
                                 [--replica-gigabytes <replica_gigabytes>]
                                 <class_name>
    Note

    The parameter <class_name> is a positional argument. It identifies the quota class for which the quotas are set. Set the value of this parameter to default. No other quota classes are supported.

    You can update the values for any of the following optional parameters:

    • --shares <shares> Adds a new value for the shares quota.
    • --snapshots <snapshots> Adds a new value for the snapshots quota.
    • --gigabytes <gigabytes> Adds a new value for the gigabytes quota.
    • --snapshot-gigabytes <snapshot_gigabytes> or --snapshot_gigabytes <snapshot_gigabytes> Adds a new value for the snapshot_gigabytes quota.
    • --share-networks <share_networks> or --share_networks <share_networks> Adds a new value for the share_networks quota.
    • --share-replicas <share_replicas>, --share_replicas <share_replicas>, or --replicas <share_replicas> Adds a new value for the share_replicas quota.
    • --replica-gigabytes <replica_gigabytes> or --replica_gigabytes <replica_gigabytes> Adds a new value for the replica_gigabytes quota.

  2. Use the information from the usage statement to update the default quotas. The following example updates the default quotas for shares and gigabytes: 

    $ manila quota-class-update default \
  --shares 30 \
  --gigabytes 512
$ manila quota-class-show default
+-----------------------+---------+
| Property              | Value   |
+-----------------------+---------+
| gigabytes             | 512     |
| id                    | default |
| replica_gigabytes     | 1000    |
| share_group_snapshots | 50      |
| share_groups          | 50      |
| share_networks        | 10      |
| share_replicas        | 100     |
| shares                | 30      |
| snapshot_gigabytes    | 1000    |
| snapshots             | 50      |
+-----------------------+---------+