Storage Guide

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the stackrc undercloud credentials file:

   $ source ~/stackrc

3. To enable active-active Block Storage service volumes, add this environment file to the stack with your other environment files and deploy the overcloud:

   /usr/share/openstack-tripleo-heat-templates/environments/cinder-volume-active-active.yaml

Procedure

1. Source the overcloud credentials file:

   $ source ~/<credentials_file>

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

2. Run the following command to verify whether all of the services for a cluster are running:

   $ cinder cluster-list --detailed

   Alternatively, run the cluster show command.

3. If any services are not running, run the following command to identify those specific services:

   $ cinder service-list

4. Run the following command to trigger the server cleanup:

   $ cinder --os-volume-api-version 3.24 work-cleanup [--cluster <cluster-name>] [--host <hostname>] [--binary <binary>] [--is-up <True|true|False|false>] [--disabled <True|true|False|false>] [--resource-id <resource-id>] [--resource-type <Volume|Snapshot>]

   Note

   Filters, such as --cluster, --host, and --binary, define what the command cleans. You can filter on cluster name, host name, type of service, and resource type, including a specific resource. If you do not apply filtering, the command attempts to clean everything that can be cleaned.

   The following example filters by cluster name:

   $ cinder --os-volume-api-version 3.24 work-cleanup --cluster tripleo@tripleo_ceph

Procedure

1. Source the overcloud credentials file:

   $ source ~/<credentials_file>

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

2. Determine the host of cinder-volume:

   $ cinder service-list

   This command will return a list containing the host of each Block Storage service (cinder-backup, cinder-scheduler, and cinder-volume). For example:

   +------------------+---------------------------+------+---------
   |      Binary      |            Host           | Zone |  Status ...
   +------------------+---------------------------+------+---------
   |  cinder-backup   |   localhost.localdomain   | nova | enabled ...
   | cinder-scheduler |   localhost.localdomain   | nova | enabled ...
   |  cinder-volume   | *localhost.localdomain@lvm* | nova | enabled ...
   +------------------+---------------------------+------+---------

3. Display the driver capabilities to determine the supported Extra Specs of a Block Storage service:

   $ cinder get-capabilities <volsvchost>

   • Replace <volsvchost> with the host of cinder-volume. For example:

     $ cinder get-capabilities localhost.localdomain@lvm
         +---------------------+-----------------------------------------+
         |     Volume stats    |                        Value            |
         +---------------------+-----------------------------------------+
         |     description     |                         None            |
         |     display_name    |                         None            |
         |    driver_version   |                        3.0.0            |
         |      namespace      | OS::Storage::Capabilities::localhost.loc...
         |      pool_name      |                         None            |
         |   storage_protocol  |                        iSCSI            |
         |     vendor_name     |                     Open Source         |
         |      visibility     |                         None            |
         | volume_backend_name |                         lvm             |
         +---------------------+-----------------------------------------+
         +--------------------+------------------------------------------+
         | Backend properties |                        Value             |
         +--------------------+------------------------------------------+
         |    compression     |      {u'type': u'boolean', u'description'...
         |        qos         |              {u'type': u'boolean', u'des ...
         |    replication     |      {u'type': u'boolean', u'description'...
         | thin_provisioning  | {u'type': u'boolean', u'description': u'S...
         +--------------------+------------------------------------------+

     The Backend properties column shows a list of Extra Spec Keys that you can set, while the Value column provides information on valid corresponding values.

Procedure

1. Log into the dashboard as an admin user.
2. Select Admin > Volumes > Volume Types.
3. Click Create Volume Type.
4. Enter the volume type name in the Name field.
5. Click Create Volume Type. The new type appears in the Volume Types table.
6. Select the volume type’s View Extra Specs action.
7. Click Create and specify the Key and Value. The key-value pair must be valid; otherwise, specifying the volume type during volume creation will result in an error.
8. Click Create. The associated setting (key-value pair) now appears in the Extra Specs table.

Procedure

1. Log into the dashboard as an admin user.
2. Select Admin > Volumes > Volume Types.
3. In the Volume Types table, select the volume type’s View Extra Specs action.

4. On the Extra Specs table of this page, you can:

   • Add a new setting to the volume type. To do this, click Create and specify the key/value pair of the new setting you want to associate to the volume type.
   • Edit an existing setting associated with the volume type by selecting the setting’s Edit action.
   • Delete existing settings associated with the volume type by selecting the extra specs' check box and clicking Delete Extra Specs in this and the next dialog screen.

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 new cinder volume type and set the is-public flag to false:

   $ cinder type-create --is-public false <type_name>

   • Replace <type_name> with the name that you want to call this new private volume type.

Procedure

1. Source the overcloud credentials file:

   $ source ~/<credentials_file>

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

2. Define, clear, or list the default volume type for a project:

   Note

   You must replace <project_id> in these commands, with the ID of the required project. To find the ID and name of each tenant, run the openstack project list command.

   • To define the default volume type for a project:

     $ cinder --os-volume-api-version 3.62 default-type-set <volume_type> <project_id>

     • Replace <volume_type> with the name or ID of the required volume type. You can run the cinder type-list command to list the name and ID of all the volume types.

   • To clear the default volume type for a project:

     $ cinder --os-volume-api-version 3.62 default-type-unset <project_id>

   • To list the default volume type for a project:

     $ cinder --os-volume-api-version 3.62 default-type-list --project <project_id>

Procedure

1. Log into the dashboard as an admin user.
2. Select Admin > Volumes > Volume Types.
3. On the QoS Specs table, click Create QoS Spec.
4. Enter a name for the QoS Spec.
5. In the Consumer field, choose the consumer of this QoS specification. For more information, see Consumers of QoS specifications.
6. Click Create. The new QoS specification is displayed in the QoS Specs table.
7. In the QoS Specs table, select the Manage Specs action of your new QoS specification to open the Specs window, where you add the QoS performance limits.
8. Click Create in the Specs window to open the Create Extra Specs window.

9. Specify the QoS property key for a QoS performance limit in the Key field, and set the performance limit value in the Value field. For more information on the available property keys, see Block Storage QoS property keys.

   Important

   Ensure that you spell the QoS property keys correctly. The volume performance limits that contain incorrectly spelled property keys are ignored.

10. Click Create to add the QoS limit to your QoS specification.
11. Repeat steps 7 to 10 for each QoS limit that you want to add to your QoS specification.

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 the QoS specification:

   $ openstack volume qos create [--consumer <qos_spec_consumer>] <qos_spec_name>

   • Optional: Replace <qos_spec_consumer> with the required consumer of this QoS specification. If not specified, the consumer defaults to both. For more information, see Consumers of QoS specifications.
   • Replace <qos_spec_name> with the name of your QoS specification.

3. Add the performance limits to the QoS specification, by specifying a separate --property <key=value> argument for each QoS limit that you want to add:

   $ openstack volume qos set --property <key>=<value> <qos_spec_name>

   • Replace <key> with the QoS property key of the required performance constraint. For more information, see Block Storage QoS property keys.

     Important

     Ensure that you spell the QoS property keys correctly. The volume performance limits that contain incorrectly spelled property keys are ignored.

   • Replace <value> with your deployment-specific limit for this performance constraint, in the measurement unit required by the QoS property key.

   • Replace <qos_spec_name> with the name or ID of your QoS specification.

     Example:

     $ openstack volume qos set \
      --property read_iops_sec=5000 \
      --property write_iops_sec=7000 \
      myqoslimits

4. Review the QoS specification:

   $ openstack volume qos list
   +--------------------------------------+---------+-----------+--------------+-----------------------------------------------------+
   | ID                                   | Name    | Consumer  | Associations | Properties                                          |
   +--------------------------------------+---------+-----------+--------------+-----------------------------------------------------+
   | 204c6ba2-c67c-4ac8-918a-03f101811235 | myqoslimits | front-end |              | read_iops_sec='5000', write_iops_sec='7000' |
   +--------------------------------------+---------+-----------+--------------+-----------------------------------------------------+

   This command provides a table of the configuration details of all the configured QoS specifications.

Procedure

1. Log into the dashboard as an admin user.
2. Select Admin > Volumes > Volume Types.
3. In the Volume Types table, select the Manage QoS Spec Association action of the required volume type.
4. Select the required QoS specification from the QoS Spec to be associated list.
5. Click Associate. The QoS specification is added to the Associated QoS Spec column of the edited volume type.

Procedure

1. Source the overcloud credentials file:

   $ source ~/<credentials_file>

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

2. Associate the required QoS specification with the required volume type:

   $ openstack volume qos associate <qos_spec_name> <volume_type>

   • Replace <qos_spec_name> with the name or ID of the QoS specification. You can run the openstack volume qos list command to list the name and ID of all the QoS specifications.
   • Replace <volume_type> with the name or ID of the volume type. You can run the cinder type-list command to list the name and ID of all the volume types.

3. Verify that the QoS specification has been associated:

   $ openstack volume qos list

   The Associations column of the output table shows which volume types are associated with this QoS specification.

Procedure

1. Log into the dashboard as an admin user.
2. Select Admin > Volumes > Volume Types.
3. In the Volume Types table, select the Manage QoS Spec Association action of the required volume type.
4. Select None from the QoS Spec to be associated list.

5. Click Associate.

   The QoS specification should be removed from the Associated QoS Spec column of the edited volume type.

Procedure

1. Source the overcloud credentials file:

   $ source ~/<credentials_file>

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

2. Disassociate the volume types associated with the QoS specification. You can either disassociate a specific volume type, or all volumes types when more than one volume type is associated to the same QoS specification:

   • To disassociate a specific volume type associated with the QoS specification:

     $ openstack volume qos disassociate <qos_spec_name> --volume-type <volume_type>

     • Replace <qos_spec_name> with the name or ID of the QoS specification. You can run the openstack volume qos list command to list the name and ID of all the QoS specifications.
     • Replace <volume_type> with the name or ID of the volume type associated with this QoS specification. You can run the cinder type-list command to list the name and ID of all the volume types.

   • To disassociate all volume types associated with the QoS specification:

     $ openstack volume qos disassociate <qos_spec_name> --all

3. Verify that the QoS specification has been disassociated:

   $ openstack volume qos list

   The Associations column of this QoS specification should either not specify the volume type or be empty.

Procedure

1. Log into the dashboard as an admin user.
2. Select Admin > Volumes > Volume Types.
3. In the Actions column of the volume to be encrypted, select Create Encryption to launch the Create Volume Type Encryption wizard.

4. From there, configure the Provider, Control Location, Cipher, and Key Size settings of the volume type’s encryption. The Description column describes each setting.

   Important

   The values listed below are the only supported options for Provider, Cipher, and Key Size.

   1. Enter luks for Provider.
   2. Enter aes-xts-plain64 for Cipher.
   3. Enter 256 for Key Size.
5. Click Create Volume Type Encryption.

1. Select Update Encryption from the Actions column of the volume type to launch the Update Volume Type Encryption wizard.
2. In Project > Compute > Volumes, check the Encrypted column in the Volumes table to determine whether the volume is encrypted.
3. If the volume is encrypted, click Yes in that column to view the encryption settings.

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 volume type:

   $ cinder type-create myEncType

3. Configure the cipher, key size, control location, and provider settings:

   $ cinder encryption-type-create --cipher aes-xts-plain64 --key-size 256 --control-location front-end myEncType luks

4. Create an encrypted volume:

   $ cinder --debug create 1 --volume-type myEncType --name myEncVol

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the stackrc undercloud credentials file:

   $ source ~/stackrc

3. Edit an environment file and add a new entry to the parameter_defaults section. This ensures that the entries are updated in the containers and are retained whenever the environment is re-deployed by director with the openstack overcloud deploy command.

4. Add a new section to an environment file using CinderApiPolicies to set the consistency group settings. The equivalent parameter_defaults section with the default settings from the JSON file appear in the following way:

   parameter_defaults:
     CinderApiPolicies: { \
        cinder-consistencygroup_create: { key: 'consistencygroup:create', value: 'group:nobody' }, \
        cinder-consistencygroup_delete: { key: 'consistencygroup:delete', value: 'group:nobody' },  \
        cinder-consistencygroup_update: { key: 'consistencygroup:update', value: 'group:nobody' }, \
        cinder-consistencygroup_get: { key: 'consistencygroup:get', value: 'group:nobody' }, \
        cinder-consistencygroup_get_all: { key: 'consistencygroup:get_all', value: 'group:nobody' }, \
        cinder-consistencygroup_create_cgsnapshot: { key: 'consistencygroup:create_cgsnapshot', value: 'group:nobody' }, \
        cinder-consistencygroup_delete_cgsnapshot: { key: 'consistencygroup:delete_cgsnapshot', value: 'group:nobody' }, \
        cinder-consistencygroup_get_cgsnapshot: { key: 'consistencygroup:get_cgsnapshot', value: 'group:nobody' }, \
        cinder-consistencygroup_get_all_cgsnapshots: { key: 'consistencygroup:get_all_cgsnapshots', value: 'group:nobody' }, \
    }

5. The value ‘group:nobody’ determines that no group can use this feature so it is effectively disabled. To enable it, change the group to another value.

6. For increased security, set the permissions for both consistency group API and volume type management API to be identical. The volume type management API is set to "rule:admin_or_owner" by default in the same /etc/cinder/policy.json_ file:

   "volume_extension:types_manage": "rule:admin_or_owner",

7. To make the consistency groups feature available to all users, set the API policy entries to allow users to create, use, and manage their own consistency groups. To do so, use rule:admin_or_owner:

   CinderApiPolicies: { \
        cinder-consistencygroup_create: { key: 'consistencygroup:create', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_delete: { key: 'consistencygroup:delete', value: 'rule:admin_or_owner' },  \
        cinder-consistencygroup_update: { key: 'consistencygroup:update', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_get: { key: 'consistencygroup:get', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_get_all: { key: 'consistencygroup:get_all', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_create_cgsnapshot: { key: 'consistencygroup:create_cgsnapshot', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_delete_cgsnapshot: { key: 'consistencygroup:delete_cgsnapshot', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_get_cgsnapshot: { key: 'consistencygroup:get_cgsnapshot', value: 'rule:admin_or_owner' }, \
        cinder-consistencygroup_get_all_cgsnapshots: { key: 'consistencygroup:get_all_cgsnapshots', value: 'rule:admin_or_owner’ }, \
    }

8. Save the updates to your environment file.
9. Add your environment file to the stack with your other environment files and deploy the overcloud.

Procedure

1. Log into the dashboard as an admin user or a volume owner.
2. Select Project > Compute > Volumes > Volume Consistency Groups.
3. Click Create Consistency Group.
4. In the Consistency Group Information tab of the wizard, enter a name and description for your consistency group. Then, specify its Availability Zone.
5. You can also add volume types to your consistency group. When you create volumes within the consistency group, the Block Storage service will apply compatible settings from those volume types. To add a volume type, click its + button from the All available volume types list.
6. Click Create Consistency Group. It appears next in the Volume Consistency Groups table.

Procedure

1. Log into the dashboard as an admin user.
2. Select Project > Compute > Volumes > Volume Consistency Groups.
3. Optional: You can change the name or description of a consistency group by selecting Edit Consistency Group from its Action column.

4. To add or remove volumes from a consistency group directly, find the consistency group you want to configure. In the Actions column of that consistency group, select Manage Volumes. This launches the Add/Remove Consistency Group Volumes wizard.

   1. To add a volume to the consistency group, click its + button from the All available volumes list.
   2. To remove a volume from the consistency group, click its - button from the Selected volumes list.
5. Click Edit Consistency Group.

Procedure

1. Source the overcloud credentials file:

   $ source ~/<credentials_file>

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

2. List all available consistency groups and their respective IDs:

   $ cinder consisgroup-list

3. Create snapshots using the consistency group:

   $ cinder cgsnapshot-create [--name <cgsnapname>] [--description "<description>"] <cgnameid>

   • Replace <cgsnapname> with the name of the snapshot.
   • Replace <description> with a description of the snapshot.
   • Replace <cgnameid> with the name or ID of the consistency group.

4. Display a list of all available consistency group snapshots:

   # cinder cgsnapshot-list

Procedure

1. Source the overcloud credentials file:

   $ source ~/<credentials_file>

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

2. To clone an existing consistency group:

   $ cinder consisgroup-create-from-src --source-cg <cgnameid> [--name <cgname>] [--description "<description>"]

   • Replace <cgnameid> with the name or ID of the consistency group you want to clone.
   • Replace <cgname> with the name of your consistency group.
   • Replace <description> with a description of your consistency group.

3. To create a consistency group from a consistency group snapshot:

   $ cinder consisgroup-create-from-src --cgsnapshot <cgsnapname> [--name <cgname>] [--description "<description>"]

   • Replace <cgsnapname> with the name or ID of the snapshot you are using to create the consistency group.

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the stackrc undercloud credentials file:

   $ source ~/stackrc

3. Use an overrides environment file or create a new one, for example multipath_overrides.yaml. Add and set the following parameter:

   parameter_defaults:
     ExtraConfig:
       cinder::config::cinder_config:
         backend_defaults/use_multipath_for_image_xfer:
           value: true

   Note

   The default settings will generate a basic multipath configuration that works for most environments. However, check with your storage vendor for recommendations, because some vendors have optimized configurations that are specific to their hardware. For more information about multipath, see Configuring device mapper multipath.

4. Optional: If you have a multipath configuration file for your overcloud deployment, then you can use the MultipathdCustomConfigFile parameter to specify the location of this file:

   parameter_defaults:
     MultipathdCustomConfigFile: <config_file_directory>/<config_file_name>

   In the following example, /home/stack is the directory of the multipath configuration file and multipath.conf is the name of this file:

   parameter_defaults:
     MultipathdCustomConfigFile: /home/stack/multipath.conf

   Note

   Other TripleO multipath parameters override any corresponding value in the local custom configuration file. For example, if MultipathdEnableUserFriendlyNames is False, the files on the overcloud nodes are updated to match, even if the setting is enabled in the local custom file.

   For more information about multipath parameters, see Multipath heat template parameters.

5. Save the updates to your overrides environment file.

6. Add your overrides environment file to the stack with your other environment files, such as:

   ----
   /usr/share/openstack-tripleo-heat-templates/environments/multipathd.yaml
   ----

7. Deploy the overcloud.

Procedure

1. Create an instance.
2. Attach a non-encrypted volume to the instance.

3. Get the name of the Compute node that contains the instance:

   $ nova show <instance> | grep OS-EXT-SRV-ATTR:host

   Replace <instance> with the name of the instance that you created.

4. Retrieve the virsh name of the instance:

   $ nova show <instance> | grep instance_name

5. Get the IP address of the Compute node:

   $ . stackrc
   $ metalsmith list | grep <compute_name>

   Replace <compute_name> with the name from the output of the nova show <instance> command to display two rows, from a table of six columns.

   Find the row in which <compute_name> is in the fourth column. The IP address of <compute_name> is in the last column of this row.

   In the following example, the IP address of compute-0 is 192.168.24.15 because compute-0 is in the fourth column of the second row:

   $ . stackrc
   $ metalsmith list | grep compute-0
   | 3b1bf72e-c425-494c-9717-d0b89bb66580 | compute-0    | 95b21d3e-36be-470d-ba5c-70d5dcd6d0b3 | compute-1    | ACTIVE | ctlplane=192.168.24.49 |
   | 72a24883-25f9-435c-bf71-a20e66be172d | compute-1    | a59f79f7-006e-4f38-a9ad-8164da47d58e | compute-0    | ACTIVE | ctlplane=192.168.24.15 |

6. SSH into the Compute node that runs the instance:

   $ ssh tripleo-admin@<compute_node_ip>

   Replace <compute_node_ip> with the IP address of the Compute node.

7. Log in to the container that runs virsh:

   $ podman exec -it nova_libvirt /bin/bash

8. Enter the following command on a Compute node instance to verify that it is using multipath in the cinder volume host location:

   virsh domblklist <virsh_instance_name> | grep /dev/dm

   Replace <virsh_instance_name> with the output of the nova show <instance> | grep instance_name command.

   If the instance shows a value other than /dev/dm-, the connection is non-multipath and you must refresh the connection info with the nova shelve and nova unshelve commands:

   $ nova shelve <instance>
   $ nova unshelve <instance>

   Note

   If you have more than one type of back end, you must verify the instances and volumes on all back ends, because connection info that each back end returns might vary.

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 new volume type for multi-attach volumes:

   $ cinder type-create multiattach

3. Enable the multiattach property for this multi-attach volume type:

   $ cinder type-key multiattach set multiattach="<is> True"

4. Run the following command to specify the back end:

   $ cinder type-key multiattach set volume_backend_name=<backend_name>

Procedure

1. Source your credentials file.

2. Run the following command to create a multi-attach volume:

   $ cinder create <volume_size> --name <volume_name> --volume-type multiattach

3. Run the following command to verify that a volume is multi-attach capable. If the volume is multi-attach capable, the multiattach field equals True.

   $ cinder show <vol_id> | grep multiattach
   
   | multiattach | True |

Procedure

1. Log into the dashboard as an admin user or volume owner.
2. Select Project > Compute > Volumes.
3. In the Actions column of the volume you want to migrate, select Change Volume Type.
4. In the Change Volume Type dialog, select the target volume type and define the new back end from the Type list.
5. If you are migrating the volume to another back end, select On Demand from the Migration Policy list. For more information, see Moving volumes between back ends.
6. Click Change Volume Type to start the migration.

Procedure

1. Source your credentials file.

2. Enter the following command to retype a volume:

   $ cinder retype <volume name or id> <new volume type name>

3. If the retype operation requires moving the volume from one back end to another, the Block Storage service requires a specific flag:

   $ cinder retype --migration-policy on-demand <volume name or id> <new volume type name>

Procedure

1. Log in to one of the Controller nodes.

2. Run the following command:

   [tripleo-admin@overcloud-controller-2 ~]$ sudo podman exec -it -u swift swift_object_server /usr/bin/swift-recon -arqlT --md5
   
   ======================================================================--> Starting reconnaissance on 3 hosts (object)
   ======================================================================[2018-12-14 14:55:47] Checking async pendings
   [async_pending] - No hosts returned valid data.
   ======================================================================[2018-12-14 14:55:47] Checking on replication
   [replication_failure] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
   [replication_success] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
   [replication_time] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
   [replication_attempted] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
   Oldest completion was 2018-12-14 14:55:39 (7 seconds ago) by 172.16.3.186:6000.
   Most recent completion was 2018-12-14 14:55:42 (4 seconds ago) by 172.16.3.174:6000.
   ======================================================================[2018-12-14 14:55:47] Checking load averages
   [5m_load_avg] low: 1, high: 2, avg: 2.1, total: 6, Failed: 0.0%, no_result: 0, reported: 3
   [15m_load_avg] low: 2, high: 2, avg: 2.6, total: 7, Failed: 0.0%, no_result: 0, reported: 3
   [1m_load_avg] low: 0, high: 0, avg: 0.8, total: 2, Failed: 0.0%, no_result: 0, reported: 3
   ======================================================================[2018-12-14 14:55:47] Checking ring md5sums
   3/3 hosts matched, 0 error[s] while checking hosts.
   ======================================================================[2018-12-14 14:55:47] Checking swift.conf md5sum
   3/3 hosts matched, 0 error[s] while checking hosts.
   ======================================================================[2018-12-14 14:55:47] Checking quarantine
   [quarantined_objects] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
   [quarantined_accounts] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
   [quarantined_containers] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
   ======================================================================[2018-12-14 14:55:47] Checking time-sync
   3/3 hosts matched, 0 error[s] while checking hosts.
   ======================================================================

3. Optional: Use the --all option to return additional output.

   This command queries all servers on the ring for the following data:

   • Async pendings: If the cluster load is too high and processes cannot update database files fast enough, some updates occur asynchronously. These numbers decrease over time.
   • Replication metrics: Review the replication timestamps; full replication passes happen frequently with few errors. An old entry, for example, an entry with a timestamp from six months ago, indicates that replication on the node has not completed in the last six months.
   • Ring md5sums: This ensures that all ring files are consistent on all nodes.
   • swift.conf md5sums: This ensures that all configuration files are consistent on all nodes.
   • Quarantined files: There must be no, or very few, quarantined files for all nodes.
   • Time-sync: All nodes must be synchronized.

Procedure

1. Edit swift_params.yaml:

   cat > swift_params.yaml << EOF
   parameter_defaults:
       ExtraConfig:
         swift::proxy::copy::object_post_as_copy: False
   EOF

2. Include the parameter file when you deploy or update the overcloud:

   openstack overcloud deploy [... previous args ...] -e swift_params.yaml

Procedure

1. Copy the roles_data.yaml from /usr/share/openstack-tripleo-heat-templates.
2. Edit the new file.
3. Remove unneeded controller roles, for example Aodh*, Ceilometer*, Ceph*, Cinder*, Glance*, Heat*, Ironic*, Manila*, Nova*, Octavia*, Swift*.
4. Locate the ObjectStorage role within roles_data.yaml.
5. Copy this role to a new role within that same file and name it ObjectProxy.

6. Replace SwiftStorage with SwiftProxy in this role.

   The example roles_data.yaml file below shows sample roles.

   - name: Controller
     description: |
   	Controller role that has all the controller services loaded and handles
   	Database, Messaging and Network functions.
     CountDefault: 1
     tags:
   	- primary
   	- controller
     networks:
   	- External
   	- InternalApi
   	- Storage
   	- StorageMgmt
   	- Tenant
     HostnameFormatDefault: '%stackname%-controller-%index%'
     ServicesDefault:
   	- OS::TripleO::Services::AuditD
   	- OS::TripleO::Services::CACerts
   	- OS::TripleO::Services::CertmongerUser
   	- OS::TripleO::Services::Clustercheck
   	- OS::TripleO::Services::Docker
   	- OS::TripleO::Services::Ec2Api
   	- OS::TripleO::Services::Etcd
   	- OS::TripleO::Services::HAproxy
   	- OS::TripleO::Services::Keepalived
   	- OS::TripleO::Services::Kernel
   	- OS::TripleO::Services::Keystone
   	- OS::TripleO::Services::Memcached
   	- OS::TripleO::Services::MySQL
   	- OS::TripleO::Services::MySQLClient
   	- OS::TripleO::Services::Ntp
   	- OS::TripleO::Services::Pacemaker
   	- OS::TripleO::Services::RabbitMQ
   	- OS::TripleO::Services::Securetty
   	- OS::TripleO::Services::Snmp
   	- OS::TripleO::Services::Sshd
   	- OS::TripleO::Services::Timezone
   	- OS::TripleO::Services::TripleoFirewall
   	- OS::TripleO::Services::TripleoPackages
   	- OS::TripleO::Services::Vpp
   
   - name: ObjectStorage
     CountDefault: 1
     description: |
   	Swift Object Storage node role
     networks:
   	- InternalApi
   	- Storage
   	- StorageMgmt
     disable_upgrade_deployment: True
     ServicesDefault:
   	- OS::TripleO::Services::AuditD
   	- OS::TripleO::Services::CACerts
   	- OS::TripleO::Services::CertmongerUser
   	- OS::TripleO::Services::Collectd
   	- OS::TripleO::Services::Docker
   	- OS::TripleO::Services::FluentdClient
   	- OS::TripleO::Services::Kernel
   	- OS::TripleO::Services::MySQLClient
   	- OS::TripleO::Services::Ntp
   	- OS::TripleO::Services::Securetty
   	- OS::TripleO::Services::SensuClient
   	- OS::TripleO::Services::Snmp
   	- OS::TripleO::Services::Sshd
   	- OS::TripleO::Services::SwiftRingBuilder
   	- OS::TripleO::Services::SwiftStorage
   	- OS::TripleO::Services::Timezone
   	- OS::TripleO::Services::TripleoFirewall
   	- OS::TripleO::Services::TripleoPackages
   
   - name: ObjectProxy
     CountDefault: 1
     description: |
   	Swift Object proxy node role
     networks:
   	- InternalApi
   	- Storage
   	- StorageMgmt
     disable_upgrade_deployment: True
     ServicesDefault:
   	- OS::TripleO::Services::AuditD
   	- OS::TripleO::Services::CACerts
   	- OS::TripleO::Services::CertmongerUser
   	- OS::TripleO::Services::Collectd
   	- OS::TripleO::Services::Docker
   	- OS::TripleO::Services::FluentdClient
   	- OS::TripleO::Services::Kernel
   	- OS::TripleO::Services::MySQLClient
   	- OS::TripleO::Services::Ntp
   	- OS::TripleO::Services::Securetty
   	- OS::TripleO::Services::SensuClient
   	- OS::TripleO::Services::Snmp
   	- OS::TripleO::Services::Sshd
   	- OS::TripleO::Services::SwiftRingBuilder
   	- OS::TripleO::Services::SwiftProxy
   	- OS::TripleO::Services::Timezone
   	- OS::TripleO::Services::TripleoFirewall
   	- OS::TripleO::Services::TripleoPackages

7. Deploy the overcloud with your regular openstack deploy command, including the new roles.

   $ openstack overcloud deploy --templates -r roles_data.yaml -e [...]

Procedure

1. Create a new JSON file called newnodes.json that contains details of the new node that you want to register:

   {
     "nodes":[
       {
           "mac":[
               "dd:dd:dd:dd:dd:dd"
           ],
           "cpu":"4",
           "memory":"6144",
           "disk":"40",
           "arch":"x86_64",
           "pm_type":"ipmi",
           "pm_user":"admin",
           "pm_password":"p@55w0rd!",
           "pm_addr":"192.168.24.207"
       },
       {
           "mac":[
               "ee:ee:ee:ee:ee:ee"
           ],
           "cpu":"4",
           "memory":"6144",
           "disk":"40",
           "arch":"x86_64",
           "pm_type":"ipmi",
           "pm_user":"admin",
           "pm_password":"p@55w0rd!",
           "pm_addr":"192.168.24.208"
       }
     ]
   }

2. Register the new nodes:

   $ source ~/stackrc
   (undercloud)$ openstack overcloud node import newnodes.json

3. Launch the introspection process for each new node:

   (undercloud)$ openstack overcloud node introspect \
    --provide <node_1> [node_2] [node_n]

   • Use the --provide option to reset all the specified nodes to an available state after introspection.
   • Replace <node_1>, [node_2], and all nodes up to [node_n] with the UUID of each node that you want to introspect.

4. Configure the image properties for each new node:

   (undercloud)$ openstack overcloud node configure <node>

Procedure

1. Source the stackrc undercloud credential file:

   $ source ~/stackrc

2. Open the overcloud-baremetal-deploy.yaml node definition file that you use to provision your bare-metal nodes.

3. Increment the count parameter for the roles that you want to scale up. For example, the following configuration increases the Object Storage node count to 4:

   - name: Controller
     count: 3
   - name: Compute
     count: 10
   - name: ObjectStorage
     count: 4

4. Optional: Configure predictive node placement for the new nodes. For example, use the following configuration to provision a new Object Storage node on node03:

   - name: ObjectStorage
     count: 4
     instances:
     - hostname: overcloud-objectstorage-0
       name: node00
     - hostname: overcloud-objectstorage-1
       name: node01
     - hostname: overcloud-objectstorage-2
       name: node02
     - hostname: overcloud-objectstorage-3
       name: node03

5. Optional: Define any other attributes that you want to assign to your new nodes. For more information about the properties you can use to configure node attributes in your node definition file, see Bare-metal node provisioning attributes.
6. If you use the Object Storage service (swift) and the whole disk overcloud image, overcloud-hardened-uefi-full, configure the size of the /srv partition based on the size of your disk and your storage requirements for /var and /srv. For more information, see Configuring whole disk partitions for the Object Storage service.

7. Provision the overcloud nodes:

   (undercloud)$ openstack overcloud node provision \
   --stack <stack> \
   --output <deployment_file> \
   /home/stack/templates/overcloud-baremetal-deploy.yaml

   • Replace <stack> with the name of the stack for which the bare-metal nodes are provisioned. If not specified, the default is overcloud.
   • Replace <deployment_file> with the name of the heat environment file to generate for inclusion in the deployment command, for example /home/stack/templates/overcloud-baremetal-deployed.yaml.

8. Monitor the provisioning progress in a separate terminal. When provisioning is successful, the node state changes from available to active:

   (undercloud)$ watch openstack baremetal node list

9. Add the generated overcloud-baremetal-deployed.yaml file to the stack with your other environment files and deploy the overcloud:

   (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
     --deployed-server \
     --disable-validations \
     ...

Procedure

1. Log in to the undercloud as the stack user and create a temporary directory:

   $ mkdir temp && cd temp/

2. Download the overcloud ring files from one of the previously existing nodes (Controller 0 in this example) to the new directory:

   $ ssh tripleo-admin@overcloud-controller-0.ctlplane 'sudo tar -czvf - /var/lib/config-data/puppet-generated/swift_ringbuilder/etc/swift/{*.builder,*.ring.gz,backups/*.builder}' > swift-rings.tar.gz

3. Extract the rings and change into the ring subdirectory:

   $ tar xzvf swift-rings.tar.gz && cd var/lib/config-data/puppet-generated/swift_ringbuilder/etc/swift/

4. Collect the values for the following variables according to your device details:

   • <device_name>:

     $ openstack baremetal introspection data save <node_name> | jq ".inventory.disks"

   • <node_ip>:

     $ metalsmith <node_name> show

   • <port>: The default port is 600x. If you altered the default, use the applicable port.
   • <builder_file>: The builder file name from step 3.
   • <weight> and <zone> variables are user-defined.

5. Use swift-ring-builder to add and update the new node to the existing rings. Replace the variables according to the device details.

   Note

   You must install the python3-swift RPM to use the swift-ring-builder command.

   $ swift-ring-builder etc/swift/<builder_file> add <zone>-<node_ip>:<port>/<device_name> <weight>

6. Rebalance the ring to ensure that the new device is used:

   $ swift-ring-builder etc/swift/<builder_file> rebalance

7. Upload the modified ring files to the Controller nodes and ensure that these ring files are used. Use a script, similar to the following example, to distribute ring files:

   #!/bin/sh
   set -xe
   
   ALL="tripleo-admin@overcloud-controller-0.ctlplane tripleo-admin@overcloud-controller-1.ctlplane tripleo-admin@overcloud-controller-2.ctlplane"

   • Upload the rings to all nodes and restart Object Storage services:

     for DST in ${ALL}; do
       cat swift-rings.tar.gz | ssh "${DST}" 'sudo tar -C / -xvzf -'
       ssh "${DST}" 'sudo podman restart swift_copy_rings'
       ssh "${DST}" 'sudo systemctl restart tripleo_swift*'
     done

Procedure

1. Use a script, similar to the following example, to distribute ring files from a previously existing Controller node to all Controller nodes and restart the Object Storage service containers on those nodes:

   #!/bin/sh
   set -xe
   
   SRC="tripleo-admin@overcloud-controller-0.ctlplane"
   ALL="tripleo-admin@overcloud-controller-0.ctlplane tripleo-admin@overcloud-controller-1.ctlplane tripleo-admin@overcloud-controller-2.ctlplane"

   • Fetch the current set of ring files:

     ssh "${SRC}" 'sudo tar -czvf - /var/lib/config-data/puppet-generated/swift_ringbuilder/etc/swift/{*.builder,*.ring.gz,backups/*.builder}' > swift-rings.tar.gz

   • Upload the rings to all nodes and restart Object Storage services:

     for DST in ${ALL}; do
       cat swift-rings.tar.gz | ssh "${DST}" 'sudo tar -C / -xvzf -'
       ssh "${DST}" 'sudo podman restart swift_copy_rings'
       ssh "${DST}" 'sudo systemctl restart tripleo_swift*'
     done

2. To confirm that the data is being moved to the new disk, run the following command on the new storage node:

   $  sudo grep -i replication  /var/log/container/swift/swift.log

Procedure

1. Source the stackrc undercloud credential file:

   $ source ~/stackrc

2. Decrement the count parameter in the overcloud-baremetal-deploy.yaml file, for the roles that you want to scale down.
3. Define the hostname and name of each node that you want to remove from the stack, if they are not already defined in the instances attribute for the role.

4. Add the attribute provisioned: false to the node that you want to remove. For example, to remove the node overcloud-objectstorage-1 from the stack, include the following snippet in your overcloud-baremetal-deploy.yaml file:

   - name: ObjectStorage
     count: 3
     instances:
     - hostname: overcloud-objectstorage-0
       name: node00
     - hostname: overcloud-objectstorage-1
       name: node01
       # Removed from cluster due to disk failure
       provisioned: false
     - hostname: overcloud-objectstorage-2
       name: node02
     - hostname: overcloud-objectstorage-3
       name: node03

   After you redeploy the overcloud, the nodes that you define with the provisioned: false attribute are no longer present in the stack. However, these nodes are still running in a provisioned state.

   Note

   To remove a node from the stack temporarily, deploy the overcloud with the attribute provisioned: false and then redeploy the overcloud with the attribute provisioned: true to return the node to the stack.

5. Delete the node from the overcloud:

   (undercloud)$ openstack overcloud node delete \
   --stack <stack> \
   --baremetal-deployment /home/stack/templates/overcloud-baremetal-deploy.yaml

   • Replace <stack> with the name of the stack for which the bare-metal nodes are provisioned. If not specified, the default is overcloud.

     Note

     Do not include the nodes that you want to remove from the stack as command arguments in the openstack overcloud node delete command.

6. Provision the overcloud nodes to generate an updated heat environment file for inclusion in the deployment command:

   (undercloud)$ openstack overcloud node provision \
   --stack <stack> \
   --output <deployment_file> \
   /home/stack/templates/overcloud-baremetal-deploy.yaml

   • Replace <deployment_file> with the name of the heat environment file to generate for inclusion in the deployment command, for example /home/stack/templates/overcloud-baremetal-deployed.yaml.

7. Add the overcloud-baremetal-deployed.yaml file generated by the provisioning command to the stack with your other environment files, and deploy the overcloud:

   (undercloud)$ openstack overcloud deploy \
     ...
     -e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
     -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
     --deployed-server \
     --disable-validations \
     ...

Procedure

1. In the dashboard, select Project > Object Store > Containers.
2. Click Create Container.

3. Specify the Container Name, and select one of the following in the Container Access field.

   Type	Description
   Private	Limits access to a user in the current project.
   Public	Permits API access to anyone with the public URL. However, in the dashboard, project users cannot see public containers and data from other projects.

4. Click Create Container.

5. Optional: New containers use the default storage policy. If you have multiple storage policies defined, for example, a default policy and another policy that enables erasure coding, you can configure a container to use a non-default storage policy:

   $ swift post -H "X-Storage-Policy:<policy>" <container_name>

   • Replace <policy> with the name or alias of the policy that you want the container to use.
   • Replace <container_name> with the name of the container.

Procedure

1. In the dashboard, select Project > Object Store > Containers.
2. Click the name of the container to which you want to add the pseudo folder.
3. Click Create Pseudo-folder.
4. Specify the name in the Pseudo-folder Name field, and click Create.

Procedure

1. In the dashboard, select Project > Object Store > Containers.
2. Browse for the container in the Containers section, and ensure that all objects are deleted. For more information, see Deleting objects from the Object Storage service.
3. Select Delete Container in the container arrow menu.
4. Click Delete Container to confirm the container removal.

Procedure

1. In the dashboard, select Project > Object Store > Containers.
2. Click the name of the container in which you want to place the uploaded object. If a pseudo folder already exists in the container, you can click its name.
3. Browse for your file, and click Upload Object.

4. Specify a name in the Object Name field:

   • You can specify pseudo folders in the name by using a / character,for example, Images/myImage.jpg. If the specified folder does not already exist, it is created when the object is uploaded.
   • A name that is not unique to the location, that is, the object already exists, overwrites the contents of the object.
5. Click Upload Object.

Procedure

1. In the dashboard, select Project > Object Store > Containers.
2. Click the name of the object’s container or folder (to display the object).
3. Click Upload Object.
4. Browse for the file to be copied, and select Copy in its arrow menu.

5. Specify the following:

   Field	Description
   Destination container	Target container for the new object.
   Path	Pseudo-folder in the destination container; if the folder does not already exist, it is created.
   Destination object name	New object’s name. If you use a name that is not unique to the location (that is, the object already exists), it overwrites the object’s previous contents.

6. Click Copy Object.

Procedure

1. In the dashboard, select Project > Object Store > Containers.
2. Browse for the object, and select Delete Object in its arrow menu.
3. Click Delete Object to confirm the object is removed.

Procedure

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

   $ vi /home/stack/templates/storage_customizations.yaml

2. Configure the storage customization YAML file to include any overrides, including enabling 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. Specify the back-end templates by using the openstack overcloud deploy command. The example configuration enables the Shared File Systems service with a NetApp back end and a CephFS-NFS back end.

   Note

   Execute source ~/stackrc before issuing the openstack overcloud deploy command.

   [stack@undercloud ~]$ source ~/stackrc
   $ 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 \
   ...

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the overcloudrc credentials file:

   $ source ~/overcloudrc

3. 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.

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the overcloudrc credentials file:

   $ source ~/overcloudrc

3. Create a storage customization YAML file. This file can be used to provide any values or overrides that suit your environment:

   $ vi /home/stack/templates/storage_customizations.yaml

4. Configure the ManilaEnabledShareProtocols parameter with the values that you want:

   parameter_defaults:
     ManilaEnabledShareProtocols:
       - NFS
       - CEPHFS

5. Include the environment file that contains your new content in the openstack overcloud deploy command by using the -e option. Ensure that you include all other environment files that are relevant to your deployment.

   $ openstack overcloud deploy \
   ...
   -e /home/stack/templates/storage_customizations.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.

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

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

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      |
   +-----------------------+---------+

Procedure

1. Retrieve the ID of the share snapshot that contains the data that you require for your new share:

   $ manila snapshot-list

2. A share created from a snapshot can be larger, but not smaller, than the snapshot. Retrieve the size of the snapshot:

   $ manila snapshot-show <snapshot-id>

3. Create a share from a snapshot:

   $ manila create <share_protocol> <size> \
      --snapshot-id <snapshot_id> \
      --name <name>

   • Replace <share_protocol> with the protocol, such as NFS.
   • Replace <size> with the size of the share to be created, in GiB.
   • Replace <snapshot_id> with the ID of the snapshot.
   • Replace <name> with the name of the new share.

4. List the shares to confirm that the share was created successfully:

   $ manila list

5. View the properties of the new share:

   $ manila show <name>

Procedure

1. Identify the snapshot you want to delete and retrieve its ID:

   $ manila snapshot-list

2. Delete the snapshot:

   $ manila snapshot-delete <snapshot>

   Note

   Repeat this step for each snapshot that you want to delete.

3. After you delete the snapshot, run the following command to confirm that you deleted the snapshot:

   $ manila snapshot-list

Procedure

1. Retrieve the IP address of the client compute instance where you plan to mount the share. Make sure that you pick the IP address that corresponds to the network that can reach the shares. In this example, it is the IP address of the StorageNFS network:

   (user) $ openstack server list -f yaml
   - Flavor: m1.micro
     ID: 0b878c11-e791-434b-ab63-274ecfc957e8
     Image: manila-test
     Name: demo-instance0
     Networks: demo-network=172.20.0.4, 10.0.0.53;
     StorageNFS=172.17.5.160
     Status: ACTIVE
   
   (user) $ manila access-allow share-01 ip 172.17.5.160

   Note

   Access to the share has its own ID (accessid).

   +-----------------+---------------------------------------+
   | Property        | Value                                 |
   +-----------------+---------------------------------------+
   | access_key      | None
   | share_id        | db3bedd8-bc82-4100-a65d-53ec51b5cba3
   | created_at      | 2018-09-17T21:57:42.000000
   | updated_at      | None
   | access_type     | ip
   | access_to       | 172.17.5.160
   | access_level    | rw
   | state           | queued_to_apply
   | id              | 875c6251-c17e-4c45-8516-fe0928004fff
   +-----------------+---------------------------------------+

2. Verify that the access configuration was successful:

   (user) $ manila access-list share-01
   
   +--------------+-------------+--------------+--------------+--------+ ...
   | id           | access_type | access_to    | access_level | state  | ...
   +--------------+-------------+--------------+--------------+--------+
   | 875c6251-... | ip          | 172.17.5.160 | rw       	   | active | ...
   +--------------+------------+--------------+--------------+---------+ ...

Procedure

1. Grant users access to the native CephFS share:

   $ manila access-allow <share-02> cephx <user-01>

   • Replace <share-02> with either the share name or the share ID.
   • Replace <user-01> with the cephx user.

2. Collect the access key for the user:

   $ manila access-list <share-02>

Procedure

1. Log in to the instance:

   (user) $ openstack server ssh demo-instance0 --login user

2. To mount an NFS share, refer to the following example for sample syntax:

   $ mount -t nfs -v <172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01> /mnt

   • Replace <172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01> with the export location of the share.
   • Retrieve the export location as described in Section 7.8.1, “Listing share export locations”.

3. To mount a native CephFS share, refer to the following example for sample syntax:

   $  mount -t ceph \ <192.168.1.7:6789,192.168.1.8:6789,192.168.1.9:6789:/volumes/_nogroup/4c55ad20-9c55-4a5e-9233-8ac64566b98c> \
   -o name=<user-01>,secret='<AQA8+ANW/<4ZWNRAAOtWJMFPEihBA1unFImJczA==>'

   • Replace <192.168.1.7:6789,192.168.1.8:6789,192.168.1.9:6789:/volumes/_nogroup/4c55ad20-9c55-4a5e-9233-8ac64566b98c> with the export location of the share.
   • Retrieve the export location as described in Section 7.8.1, “Listing share export locations”.
   • Replace <user-01> with the cephx user who has access to the share.
   • Replace the secret value with the access key that you collected in Section 7.7.2, “Granting access to a native CephFS share”.

Procedure

1. To create the share, you can use a share type that specifies some capabilities that you want the share to have. Cloud administrators can create share types. View the available share types:

   clouduser1@client:~$ manila type-list
   +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
   | ID                                   | Name        | visibility | is_default | required_extra_specs                 | optional_extra_specs                       | Description |
   +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
   | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 | dhss_false  | public     | YES        | driver_handles_share_servers : False | create_share_from_snapshot_support : True  | None        |
   |                                      |             |            |            |                                      | mount_snapshot_support : False             |             |
   |                                      |             |            |            |                                      | revert_to_snapshot_support : False         |             |
   |                                      |             |            |            |                                      | snapshot_support : True                    |             |
   | 277c1089-127f-426e-9b12-711845991ea1 | dhss_true   | public     | -          | driver_handles_share_servers : True  | create_share_from_snapshot_support : True  | None        |
   |                                      |             |            |            |                                      | mount_snapshot_support : False             |             |
   |                                      |             |            |            |                                      | revert_to_snapshot_support : False         |             |
   |                                      |             |            |            |                                      | snapshot_support : True                    |             |
   +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+

   In this example, two share types are available.

2. To use a share type that specifies the driver_handles_share_servers=True capability, you must create a share network on which to export the share. Create a share network from a private project network.

   clouduser1@client:~$ openstack subnet list
   +--------------------------------------+---------------------+--------------------------------------+---------------------+
   | ID                                   | Name                | Network                              | Subnet              |
   +--------------------------------------+---------------------+--------------------------------------+---------------------+
   | 78c6ac57-bba7-4922-ab81-16cde31c2d06 | private-subnet      | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 | 10.0.0.0/26         |
   | a344682c-718d-4825-a87a-3622b4d3a771 | ipv6-private-subnet | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 | fd36:18fc:a8e9::/64 |
   +--------------------------------------+---------------------+--------------------------------------+---------------------+
   
   clouduser1@client:~$ manila share-network-create --name mynet --neutron-net-id 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 --neutron-subnet-id 78c6ac57-bba7-4922-ab81-16cde31c2d06
   +-------------------+--------------------------------------+
   | Property          | Value                                |
   +-------------------+--------------------------------------+
   | network_type      | None                                 |
   | name              | mynet                                |
   | segmentation_id   | None                                 |
   | created_at        | 2018-10-09T21:32:22.485399           |
   | neutron_subnet_id | 78c6ac57-bba7-4922-ab81-16cde31c2d06 |
   | updated_at        | None                                 |
   | mtu               | None                                 |
   | gateway           | None                                 |
   | neutron_net_id    | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 |
   | ip_version        | None                                 |
   | cidr              | None                                 |
   | project_id        | cadd7139bc3148b8973df097c0911016     |
   | id                | 0b0fc320-d4b5-44a1-a1ae-800c56de550c |
   | description       | None                                 |
   +-------------------+--------------------------------------+
   
   clouduser1@client:~$ manila share-network-list
   +--------------------------------------+-------+
   | id                                   | name  |
   +--------------------------------------+-------+
   | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 | mynet |
   +--------------------------------------+-------+

3. Create the share:

   clouduser1@client:~$ manila create nfs 1 --name software_share --share-network mynet --share-type dhss_true
   +---------------------------------------+--------------------------------------+
   | Property                              | Value                                |
   +---------------------------------------+--------------------------------------+
   | status                                | creating                             |
   | share_type_name                       | dhss_true                            |
   | description                           | None                                 |
   | availability_zone                     | None                                 |
   | share_network_id                      | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 |
   | share_server_id                       | None                                 |
   | share_group_id                        | None                                 |
   | host                                  |                                      |
   | revert_to_snapshot_support            | False                                |
   | access_rules_status                   | active                               |
   | snapshot_id                           | None                                 |
   | create_share_from_snapshot_support    | False                                |
   | is_public                             | False                                |
   | task_state                            | None                                 |
   | snapshot_support                      | False                                |
   | id                                    | 243f3a51-0624-4bdd-950e-7ed190b53b67 |
   | size                                  | 1                                    |
   | source_share_group_snapshot_member_id | None                                 |
   | user_id                               | 61aef4895b0b41619e67ae83fba6defe     |
   | name                                  | software_share                       |
   | share_type                            | 277c1089-127f-426e-9b12-711845991ea1 |
   | has_replicas                          | False                                |
   | replication_type                      | None                                 |
   | created_at                            | 2018-10-09T21:12:21.000000           |
   | share_proto                           | NFS                                  |
   | mount_snapshot_support                | False                                |
   | project_id                            | cadd7139bc3148b8973df097c0911016     |
   | metadata                              | {}                                   |
   +---------------------------------------+--------------------------------------+

4. View the status of the share:

   clouduser1@client:~$ manila list
   +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
   | ID                                   | Name           | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone |
   +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
   | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1    | NFS         | error  | False     | dhss_true       |      | None              |
   +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+

   In this example, an error occurred during the share creation.

5. To view the user support message, run the message-list command. Use the --resource-id to filter to the specific share you want to find out about.

   clouduser1@client:~$ manila message-list
   +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
   | ID                                   | Resource Type | Resource ID                          | Action ID | User Message                                                                                             | Detail ID | Created At                 |
   +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
   | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE         | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001       | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008       | 2018-10-09T21:12:21.000000 |
   +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+

   In the User Message column, notice that the Shared File Systems service failed to create the share because of a capabilities mismatch.

6. To view more message information, run the message-show command, followed by the ID of the message from the message-list command:

   clouduser1@client:~$ manila message-show 7d411c3c-46d9-433f-9e21-c04ca30b209c
   +---------------+----------------------------------------------------------------------------------------------------------+
   | Property      | Value                                                                                                    |
   +---------------+----------------------------------------------------------------------------------------------------------+
   | request_id    | req-0a875292-6c52-458b-87d4-1f945556feac                                                                 |
   | detail_id     | 008                                                                                                      |
   | expires_at    | 2018-11-08T21:12:21.000000                                                                               |
   | resource_id   | 243f3a51-0624-4bdd-950e-7ed190b53b67                                                                     |
   | user_message  | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. |
   | created_at    | 2018-10-09T21:12:21.000000                                                                               |
   | message_level | ERROR                                                                                                    |
   | id            | 7d411c3c-46d9-433f-9e21-c04ca30b209c                                                                     |
   | resource_type | SHARE                                                                                                    |
   | action_id     | 001                                                                                                      |
   +---------------+----------------------------------------------------------------------------------------------------------+

7. As the cloud user, you can check capabilities through the share type so you can review the share types available. The difference between the two share types is the value of driver_handles_share_servers:

   clouduser1@client:~$ manila type-list
   +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
   | ID                                   | Name        | visibility | is_default | required_extra_specs                 | optional_extra_specs                       | Description |
   +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
   | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 | dhss_false  | public     | YES        | driver_handles_share_servers : False | create_share_from_snapshot_support : True  | None        |
   |                                      |             |            |            |                                      | mount_snapshot_support : False             |             |
   |                                      |             |            |            |                                      | revert_to_snapshot_support : False         |             |
   |                                      |             |            |            |                                      | snapshot_support : True                    |             |
   | 277c1089-127f-426e-9b12-711845991ea1 | dhss_true   | public     | -          | driver_handles_share_servers : True  | create_share_from_snapshot_support : True  | None        |
   |                                      |             |            |            |                                      | mount_snapshot_support : False             |             |
   |                                      |             |            |            |                                      | revert_to_snapshot_support : False         |             |
   |                                      |             |            |            |                                      | snapshot_support : True                    |             |
   +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+

8. Create a share with the other available share type:

   clouduser1@client:~$ manila create nfs 1 --name software_share --share-network mynet --share-type dhss_false
   +---------------------------------------+--------------------------------------+
   | Property                              | Value                                |
   +---------------------------------------+--------------------------------------+
   | status                                | creating                             |
   | share_type_name                       | dhss_false                           |
   | description                           | None                                 |
   | availability_zone                     | None                                 |
   | share_network_id                      | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 |
   | share_group_id                        | None                                 |
   | revert_to_snapshot_support            | False                                |
   | access_rules_status                   | active                               |
   | snapshot_id                           | None                                 |
   | create_share_from_snapshot_support    | True                                 |
   | is_public                             | False                                |
   | task_state                            | None                                 |
   | snapshot_support                      | True                                 |
   | id                                    | 2d03d480-7cba-4122-ac9d-edc59c8df698 |
   | size                                  | 1                                    |
   | source_share_group_snapshot_member_id | None                                 |
   | user_id                               | 5c7bdb6eb0504d54a619acf8375c08ce     |
   | name                                  | software_share                       |
   | share_type                            | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 |
   | has_replicas                          | False                                |
   | replication_type                      | None                                 |
   | created_at                            | 2018-10-09T21:24:40.000000           |
   | share_proto                           | NFS                                  |
   | mount_snapshot_support                | False                                |
   | project_id                            | cadd7139bc3148b8973df097c0911016     |
   | metadata                              | {}                                   |
   +---------------------------------------+--------------------------------------+

   In this example, the second share creation attempt fails.

9. View the user support message:

   clouduser1@client:~$ manila list
   +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
   | ID                                   | Name           | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone |
   +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
   | 2d03d480-7cba-4122-ac9d-edc59c8df698 | software_share | 1    | NFS         | error  | False     | dhss_false      |      | nova              |
   | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1    | NFS         | error  | False     | dhss_true       |      | None              |
   +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
   
   clouduser1@client:~$ manila message-list
   +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
   | ID                                   | Resource Type | Resource ID                          | Action ID | User Message                                                                                             | Detail ID | Created At                 |
   +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
   | ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 | SHARE         | 2d03d480-7cba-4122-ac9d-edc59c8df698 | 002       | create: Driver does not expect share-network to be provided with current configuration.                  | 003       | 2018-10-09T21:24:40.000000 |
   | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE         | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001       | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008       | 2018-10-09T21:12:21.000000 |
   +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+

   The service does not expect a share network for the share type that you used.

10. Without consulting the administrator, you can discover that the administrator has not made available a storage back end that supports exporting shares directly on to your private neutron network. Create the share without the share-network parameter:

    clouduser1@client:~$ manila create nfs 1 --name software_share --share-type dhss_false
    +---------------------------------------+--------------------------------------+
    | Property                              | Value                                |
    +---------------------------------------+--------------------------------------+
    | status                                | creating                             |
    | share_type_name                       | dhss_false                           |
    | description                           | None                                 |
    | availability_zone                     | None                                 |
    | share_network_id                      | None                                 |
    | share_group_id                        | None                                 |
    | revert_to_snapshot_support            | False                                |
    | access_rules_status                   | active                               |
    | snapshot_id                           | None                                 |
    | create_share_from_snapshot_support    | True                                 |
    | is_public                             | False                                |
    | task_state                            | None                                 |
    | snapshot_support                      | True                                 |
    | id                                    | 4d3d7fcf-5fb7-4209-90eb-9e064659f46d |
    | size                                  | 1                                    |
    | source_share_group_snapshot_member_id | None                                 |
    | user_id                               | 5c7bdb6eb0504d54a619acf8375c08ce     |
    | name                                  | software_share                       |
    | share_type                            | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 |
    | has_replicas                          | False                                |
    | replication_type                      | None                                 |
    | created_at                            | 2018-10-09T21:25:40.000000           |
    | share_proto                           | NFS                                  |
    | mount_snapshot_support                | False                                |
    | project_id                            | cadd7139bc3148b8973df097c0911016     |
    | metadata                              | {}                                   |
    +---------------------------------------+--------------------------------------+

11. Ensure that the share was created successfully:

    clouduser1@client:~$ manila list
    +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
    | ID                                   | Name           | Size | Share Proto | Status    | Is Public | Share Type Name | Host | Availability Zone |
    +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
    | 4d3d7fcf-5fb7-4209-90eb-9e064659f46d | software_share | 1    | NFS         | available | False     | dhss_false      |      | nova              |
    | 2d03d480-7cba-4122-ac9d-edc59c8df698 | software_share | 1    | NFS         | error     | False     | dhss_false      |      | nova              |
    | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1    | NFS         | error     | False     | dhss_true       |      | None              |
    +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+

12. Delete the shares and support messages:

    clouduser1@client:~$ manila message-list
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    | ID                                   | Resource Type | Resource ID                          | Action ID | User Message                                                                                             | Detail ID | Created At                 |
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    | ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 | SHARE         | 2d03d480-7cba-4122-ac9d-edc59c8df698 | 002       | create: Driver does not expect share-network to be provided with current configuration.                  | 003       | 2018-10-09T21:24:40.000000 |
    | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE         | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001       | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008       | 2018-10-09T21:12:21.000000 |
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    
    clouduser1@client:~$ manila delete 2d03d480-7cba-4122-ac9d-edc59c8df698 243f3a51-0624-4bdd-950e-7ed190b53b67
    clouduser1@client:~$ manila message-delete ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 7d411c3c-46d9-433f-9e21-c04ca30b209c
    
    clouduser1@client:~$ manila message-list
    +----+---------------+-------------+-----------+--------------+-----------+------------+
    | ID | Resource Type | Resource ID | Action ID | User Message | Detail ID | Created At |
    +----+---------------+-------------+-----------+--------------+-----------+------------+
    +----+---------------+-------------+-----------+--------------+-----------+------------+

Procedure

1. Verify the access control list of the share to ensure that the rule that corresponds to your client is correct and has been successfully applied.

   $ manila access-list share-01

   In a successful rule, the state attribute equals active.

2. If the share type parameter is configured to driver_handles_share_servers=False, copy the hostname or IP address from the export location and ping it to confirm connectivity to the NAS server:

   $ ping -c 1 172.17.5.13
   PING 172.17.5.13 (172.17.5.13) 56(84) bytes of data.
   64 bytes from 172.17.5.13: icmp_seq=1 ttl=64 time=0.048 ms--- 172.17.5.13 ping statistics ---
   1 packets transmitted, 1 received, 0% packet loss, time 0ms
   rtt min/avg/max/mdev = 7.851/7.851/7.851/0.000 ms
   If using the NFS protocol, you may verify that the NFS server is ready to respond to NFS rpcs on the proper port:
   $ rpcinfo -T tcp -a 172.17.5.13.8.1 100003 4
   program 100003 version 4 ready and waiting

   Note

   The IP address is written in universal address format (uaddr), which adds two extra octets (8.1) to represent the NFS service port, 2049.