Storage Guide

Procedure

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

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

   $ cinder service-list

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

   $ cinder 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 work-cleanup --cluster tripleo@tripleo_ceph

Procedure

1. As an admin user in the dashboard, select Admin > Volumes > Volume Types.
2. Click Create Volume Type.
3. Enter the volume type name in the Name field.
4. Click Create Volume Type. The new type appears in the Volume Types table.
5. Select the volume type’s View Extra Specs action.
6. 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. For instance, to specify a back end for this volume type, add the volume_backend_name Key and set the Value to the name of the required back end.
7. Click Create. The associated setting (key-value pair) now appears in the Extra Specs table.

Procedure

1. As an admin user in the dashboard, select Admin > Volumes > Volume Types.
2. In the Volume Types table, select the volume type’s View Extra Specs action.

3. 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. As an admin user in the dashboard, select Admin > Volumes > Volume Types.
2. On the QOS Specs table, click Create QOS Spec.
3. Enter a name for the QOS Spec.

4. In the Consumer field, specify where the QOS policy should be enforced:

   Table 2.1. Consumer Types

   Type	Description
   back-end	QOS policy will be applied to the Block Storage back end.
   front-end	QOS policy will be applied to Compute.
   both	QOS policy will be applied to both Block Storage and Compute.

5. Click Create. The new QOS Spec should now appear in the QOS Specs table.
6. In the QOS Specs table, select the new spec’s Manage Specs action.

7. Click Create, and specify the Key and Value. The key-value pair must be valid; otherwise, specifying a volume type associated with this QOS Spec during volume creation will fail.

   For example, to set read limit IOPS to 500, use the following Key/Value pair:

   read_iops_sec=500

8. Click Create. The associated setting (key-value pair) now appears in the Key-Value Pairs table.

Procedure

1. As an administrator in the dashboard, select Admin > Volumes > Volume Types.
2. In the Volume Types table, select the type’s Manage QOS Spec Association action.
3. Select a QOS Spec from the QOS Spec to be associated list. To disassociate a QOS specification from an existing volume type, select None.
4. Click Associate. The selected QOS Spec now appears in the Associated QOS Spec column of the edited volume type.

Procedure

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

3. 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.
4. 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. Create a volume type:

   $ cinder type-create encrypt-type

2. 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 encrypt-type luks

3. Create an encrypted volume:

   $ cinder --debug create 1 --volume-type encrypt-type --name DemoEncVol

Procedure

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

2. 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' }, \
    }

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

4. 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",

5. 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’ }, \
    }

6. When you have created the environment file in /home/stack/templates/, log in as the stack user and deploy the configuration:

   $ openstack overcloud deploy --templates \
   -e /home/stack/templates/<ENV_FILE>.yaml

   Replace <ENV_FILE.yaml> with the name of the file with the ExtraConfig settings you added.

   Important

   If you passed any extra environment files when you created the overcloud, pass them again here by using the -e option to avoid making undesired changes to the overcloud.

Procedure

1. As an admin user in the dashboard, select Project > Compute > Volumes > Volume Consistency Groups.
2. Click Create Consistency Group.
3. In the Consistency Group Information tab of the wizard, enter a name and description for your consistency group. Then, specify its Availability Zone.
4. 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.
5. Click Create Consistency Group. It appears next in the Volume Consistency Groups table.

Procedure

1. Optional: You can change the name or description of a consistency group by selecting Edit Consistency Group from its Action column.
2. To add or remove volumes from a consistency group directly, as an admin user in the dashboard, select Project > Compute > Volumes > Volume Consistency Groups.

3. 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.
4. Click Edit Consistency Group.

Procedure

1. Log in as admin user from the command line on the node that hosts the openstack-cinder-api and enter:

   # export OS_VOLUME_API_VERSION=2

   This configures the client to use version 2 of the openstack-cinder-api.

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 (optional).
   • <DESCRIPTION> with a description of the snapshot (optional).
   • <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. To clone an existing consistency group:

   # cinder consisgroup-create-from-src --source-cg <CGNAMEID> --name <CGNAME> --description "<DESCRIPTION>"

   Replace:

   • <CGNAMEID> is the name or ID of the consistency group you want to clone.
   • <CGNAME> is the name of your consistency group (optional).
   • <DESCRIPTION> is a description of your consistency group (optional).

2. 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 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 the Configuring device mapper multipath guide.

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

   1. You must copy your multipath configuration file to the /var/lib/mistral directory:

           $ sudo cp <config_file_name> /var/lib/mistral

      Replace <config_file_name> with the name of your file.

   2. Set the MultipathdCustomConfigFile parameter to this location of your multipath configuration file:

           parameter_defaults:
                MultipathdCustomConfigFile: /var/lib/mistral/<config_file_name>

      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. Include the environment file in the openstack overcloud deploy command with any other environment files that are relevant to your environment:

   $ openstack overcloud deploy \
   --templates \
   …
   -e <existing_overcloud_environment_files> \
   -e /usr/share/openstack-tripleo-heat-templates/environments/multipathd.yaml
   -e multipath_overrides.yaml \
   …

Procedure

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

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 VM that you booted.

4. Retrieve the virsh name of the instance:

   $ nova show INSTANCE | grep instance_name

   Replace INSTANCE with the name of the VM that you booted.

5. Get the IP address of the Compute node:

   $ . stackrc
   $ nova list | grep compute_name

   Replace compute_name with the name from the output of the nova show INSTANCE command.

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

   $ ssh heat-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. In the dashboard, select Project > Compute > Volumes.
2. In the Actions column of the volume you want to migrate, select Change Volume Type.
3. In the Change Volume Type dialog, select the target volume type and define the new back end from the Type list.
4. If you are migrating the volume to another back end, select On Demand from the Migration Policy list. For more information, see Section 4.4, “Moving volumes between back ends”.
5. Click Change Volume Type to start the migration.

Procedure

1. Enter the following command to retype a volume:

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

2. 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. Run the following commands to create a multi-attach volume type:

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

   Note

   This procedure creates a volume on any back end that supports multiattach. Therefore, if there are two back ends that support multiattach, the scheduler decides which back end to use based on the available space at the time of creation.

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

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

Procedure

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

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

2. 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 in to one of the Controller nodes.

2. Run the following command:

   [root@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*, Mistral*, 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. Log in to the undercloud as the stack user and source the stackrc credentials file:

   $ source ~/stackrc

2. Create the following directory:

   $ mkdir temp && cd temp/

3. Download the overcloud rings builder file to the new directory:

   $ openstack object save overcloud-swift-rings swift-rings.tar.gz

4. Extract the rings:

   $ tar xzvf swift-rings.tar.gz

5. Create a directory to back up the original version of the rings:

   $ mkdir backup && cp swift-rings.tar.gz backup/

   Object Storage ring files are located in the etc/swift folder.

6. 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>:

      openstack server show <node_name>

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

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

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

8. Upload the modified ring files to the Object Storage service on the undercloud:

   $ tar cvzf swift-rings.tar.gz etc/
   $ openstack object create overcloud-swift-rings swift-rings.tar.gz

Procedure

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

   cd etc/swift/
   for j in 8 11 23; do
     ssh heat-admin@192.168.24."$j" "rm *.ring.gz"
     for i in account.ring.gz container.ring.gz object.ring.gz; do
       scp $i heat-admin@192.168.24."$j":~/
       ssh heat-admin@192.168.24."$j" "sudo cp -f "$i" /var/lib/config-data/puppet-generated/swift/etc/swift/"
       ssh heat-admin@192.168.24."$j" "sudo chown root:root /var/lib/config-data/puppet-generated/swift/etc/swift/"$i""
       ssh heat-admin@192.168.24."$j" "sudo restorecon /var/lib/config-data/puppet-generated/swift/etc/swift/"$i""
     done
     ssh heat-admin@192.168.24."$j" "rm *.builder"
     for i in account.builder container.builder object.builder; do
       scp $i heat-admin@192.168.24."$j":~/
       ssh heat-admin@192.168.24."$j" "cat "$i" | sudo tee  /var/lib/config-data/puppet-generated/swift/etc/swift/"$i" >/dev/null"
     done
     ssh heat-admin@192.168.24."$j" 'for k in `sudo podman ps --format "{{.Names}}" | grep swift`; do sudo podman restart $k; done'
   done
   cd ../../

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. Log in to the undercloud as the stack user and source the stackrc credentials file:

   $ source ~/stackrc

2. Use the ObjectStorageCount parameter to decrease the Object Storage count by 1. This parameter is usually located in node-info.yaml, which is the environment file that contains your node counts:

   parameter_defaults:
     ObjectStorageCount: 3

3. Delete the IP address of the node that you removed from the ObjectStorageIPs parameter in the node-info.yaml file:

   ObjectStorageIPs: <ip_address>

4. Create an environment file, for example, remove-object-node.yaml. This file identifies and removes the Object Storage node that you specify. The following example content specifies the removal of overcloud-objectstorage-1:

   parameter_defaults:
     ObjectStorageRemovalPolicies:
       [{'resource_list': ['1']}]

5. Include both the node-info.yaml and remove-object-node.yaml files in the deployment command:

   $ openstack overcloud deploy \
   --templates \
   …
   -e <existing_overcloud_environment_files> \
   -e node-info.yaml \
   -e remove-object-node.yaml \
   …

   Director deletes the Object Storage node from the overcloud and updates the rest of the nodes on the overcloud to accommodate the node removal.

6. List active nodes to verify that you removed the correct node:

   $ openstack server list

7. On the undercloud node, delete the remove-object-node.yaml file so that it is not included in future redeployments:

   $ rm <file_path>/remove-object-node.yaml

Procedure

1. Log in to the undercloud as the stack user and source the stackrc credentials file:

   $ source ~/stackrc

2. Use the ObjectStorageCount parameter to decrease the Object Storage count by 1. This parameter is usually located in node-info.yaml, which is the environment file that contains your node counts:

   parameter_defaults:
     ObjectStorageCount: 3

3. Delete the IP address of the node that you removed from the ObjectStorageIPs parameter in the node-info.yaml file:

   ObjectStorageIPs: <ip_address>

4. Create an environment file, for example, remove-object-node.yaml. This file identifies and removes the Object Storage node that you specify. The following example content specifies the removal of overcloud-objectstorage-1:

   parameter_defaults:
     ObjectStorageRemovalPolicies:
       [{'resource_list': ['1']}]

5. Include both the node-info.yaml and remove-object-node.yaml files in the deployment command:

   $ openstack overcloud deploy \
   --templates \
   …
   -e <existing_overcloud_environment_files> \
   -e node-info.yaml \
   -e remove-object-node.yaml \
   …

   Director deletes the Object Storage node from the overcloud and updates the rest of the nodes on the overcloud to accommodate the node removal.

6. List active nodes to verify that you removed the correct node:

   $ openstack server list

7. On the undercloud node, delete the remove-object-node.yaml file so that it is not included in future redeployments:

   $ rm <file_path>/remove-object-node.yaml

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, and 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 an object.
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 the 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'

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 through 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. Discover the available share types:

   $ manila type-list

   The command output lists the name and ID of the share type.

Procedure

1. List the shares:

   (user) [stack@undercloud-0 ~]$ manila list
   
   +--------------------------------------+----------+-----+-----------+           | ID                                   | Name     | ... | Status    ...
   +--------------------------------------+----------+-----+-----------+
   | 8c3bedd8-bc82-4100-a65d-53ec51b5fe81 | share-01 | ... | available ...
   +--------------------------------------+----------+-----+-----------+

2. View the export locations of the share:

   (user) [stack@undercloud-0 ~]$ manila share-export-location-list share-01
   
    +------------------------------------------------------------------
    | Path
    |  172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01
    +------------------------------------------------------------------

3. View the parameters for the share:

   $ manila share-export-location-show <id>

   Note

   You use the export location to mount the share in Section 6.9.2, “Mounting the share”.

Procedure

1. Create a security group for the StorageNFS port that allows packets to egress the port, but which does not allow ingress packets from unestablished connections:

   (user) [stack@undercloud-0 ~]$ openstack security group create no-ingress -f yaml
   created_at: '2018-09-19T08:19:58Z'
   description: no-ingress
   id: 66f67c24-cd8b-45e2-b60f-9eaedc79e3c5
   name: no-ingress
   project_id: 1e021e8b322a40968484e1af538b8b63
   revision_number: 2
   rules: 'created_at=''2018-09-19T08:19:58Z'', direction=''egress'', ethertype=''IPv4'',
    id=''6c7f643f-3715-4df5-9fef-0850fb6eaaf2'', updated_at=''2018-09-19T08:19:58Z''
   
    created_at=''2018-09-19T08:19:58Z'', direction=''egress'', ethertype=''IPv6'',                                                          id=''a8ca1ac2-fbe5-40e9-ab67-3e55b7a8632a'', updated_at=''2018-09-19T08:19:58Z'''
   updated_at: '2018-09-19T08:19:58Z'

2. Create a port on the StorageNFS network with security enforced by the no-ingress security group.

   (user) [stack@undercloud-0 ~]$ openstack port create nfs-port0 --network StorageNFS --security-group no-ingress -f yaml
   
   admin_state_up: UP
   allowed_address_pairs: ''
   binding_host_id: null
   binding_profile: null
   binding_vif_details: null
   binding_vif_type: null
   binding_vnic_type: normal
   created_at: '2018-09-19T08:03:02Z'
   data_plane_status: null
   description: ''
   device_id: ''
   device_owner: ''
   dns_assignment: null
   dns_name: null
   extra_dhcp_opts: ''
   fixed_ips: ip_address='172.17.5.160', subnet_id='7bc188ae-aab3-425b-a894-863e4b664192'
   id: 7a91cbbc-8821-4d20-a24c-99c07178e5f7
   ip_address: null
   mac_address: fa:16:3e:be:41:6f
   name: nfs-port0
   network_id: cb2cbc5f-ea92-4c2d-beb8-d9b10e10efae
   option_name: null
   option_value: null
   port_security_enabled: true
   project_id: 1e021e8b322a40968484e1af538b8b63
   qos_policy_id: null
   revision_number: 6
   security_group_ids: 66f67c24-cd8b-45e2-b60f-9eaedc79e3c5
   status: DOWN
   subnet_id: null
   tags: ''
   trunk_details: null
   updated_at: '2018-09-19T08:03:03Z'

   Note

   StorageNFSSubnet assigned IP address 172.17.5.160 to nfs-port0.

3. Add nfs-port0 to a Compute instance.

   (user) [stack@undercloud-0 ~]$ openstack server add port instance0 nfs-port0
   (user) [stack@undercloud-0 ~]$ 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

   In addition to its private and floating addresses, the Compute instance is assigned a port with the IP address 172.17.5.160 on the StorageNFS network that you can use to mount NFS shares when access is granted to that address for the share in question.

   Note

   You might need to adjust the networking configuration on the Compute instance and restart the services for the Compute instance to activate an interface with this address.

Procedure

1. Log in to the instance.

2. Configure the IPv6 interface address:

   $ sudo ip address add fd00:fd00:fd00:7000::c/64 dev eth1

3. Activate the interface:

   $ sudo ip link set dev eth1 up

4. Ping the IPv6 address in the export location of the share to test interface connectivity:

   $ ping -6  fd00:fd00:fd00:7000::21

5. Alternatively, verify that you can reach the NFS server through Telnet:

   $ sudo dnf install -y telnet
   $ telnet fd00:fd00:fd00:7000::21 2049

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) [stack@undercloud-0 ~]$ 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) [stack@undercloud-0 ~]$ 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) [stack@undercloud-0 ~]$ manila access-list share-01
   
   +--------------+-------------+--------------+--------------+--------+ ...
   | id           | access_type | access_to    | access_level | state  | ...
   +--------------+-------------+--------------+--------------+--------+
   | 875c6251-... | ip          | 172.17.5.160 | rw       	   | active | ...
   +--------------+------------+--------------+--------------+---------+ ...

Procedure

1. Retrieve the export location of a share:

   (user) [stack@undercloud-0 ~]$ manila share-export-location-list share-01

   When multiple export locations exist, choose one for which the value of the preferred metadata field equals True. If no preferred locations exist, you can use any export location.

Procedure

1. Log in to the instance and run the following command:

   (user) [stack@undercloud-0 ~]$ openstack server ssh demo-instance0 --login root
   # hostname
   demo-instance0

2. Mount the share on an IPv4 network by using the export location:

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

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.

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