The OpenStack Shared File Systems service (manila) enables users to provision shared file systems that can be consumed by multiple compute instances.
4.2. Creating and Managing Share Types
When creating a share, share types are used to select an appropriate storage back end. OpenStack director configures the Shared File System service with a default share type named default, but does not itself create the share type.
After deploying the overcloud, as the cloud administrator, create this share type by running the following command:
# manila type-create default <spec_driver_handles_share_servers>
The <spec_driver_handles_share_servers> parameter is a boolean value:
-
For CephFS via NFS, the value is
false.
For NetApp back ends, the value can be true or false; set <spec_driver_handles_share_servers> to match the value of the ManilaNetappDriverHandlesShareServers parameter, as described in the NetApp Back End Guide for the Shared File System Service guide.
The cloud administrator can add additional specifications to the default share type and create additional share types, if that is useful for multiple configured back ends.
For example:
Set up the default share type to select a CephFS back end and an additional share type that picks a NetApp driver_handles_share_servers=True back end using the following commands:
(overcloud) [stack@undercloud-0 ~]$ manila type-create default false --extras-specs share_backend_name='cephfs'
(overcloud) [stack@undercloud-0 ~]$ manila type-create netapp true --extra-specs share_backend_name='tripleo_netapp'
By default, share types are public, which means they are visible to and usable by all cloud tenants. To make private share types, whose use is scoped by keystone projects, or to set additional share-type options, see the Security and Hardening Guide.
Create a share by using a command similar to the following:
$ manila create [--share-type <SHARETYPE>] [--name <SHARENAME>] PROTO GB
Where:
SHARETYPE applies settings associated with the specified share type.
-
OPTIONAL: if not supplied, the
default share type is used.
SHARENAME is the name of the share.
-
OPTIONAL: shares are not required to have a name, nor is the name guaranteed to be unique.
PROTO is the share protocol you want to use.
-
For CephFS with NFS, PROTO is
nfs.
-
For NetApp, PROTO is
nfs or cifs.
-
GB is the size of the share in gigabytes.
For example, in Section 4.2, “Creating and Managing Share Types”, the cloud administrator created a default share type that selects a CephFS back end and another share type named netapp that selects a NetApp back end.
Using these share types, create a 10 GB NFS share named share-01 on the CephFS back end by running the following command:
(user) [stack@undercloud-0 ~]$ manila create --name share-01 nfs 10
+---------------------------------------+----------------------------
| Property | Value +---------------------------------------+----------------------------
| status | creating
| share_type_name | default | 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 | False | is_public | False | task_state | None | snapshot_support | False | id | 8c3bedd8-bc82-4100-a65d-53ec51b5fe81
| size | 10 | source_share_group_snapshot_member_id | None | user_id | 19f014d7b5fd43519363c5bd75da864c
| name | share-01 | share_type | 89415974-3f82-4a73-8efc-9a4f9970dc00
| has_replicas | False | replication_type | None | created_at | 2018-09-17T16:00:07.000000 | share_proto | NFS | mount_snapshot_support | False | project_id | b0434b7f2c5943e797a24edd958d95e6
| metadata | {} |+--------------------------------------+----------------------------
Optionally, create a 20 GB NFS share named share-02 on the NetApp back end by running the following command:
(user) [stack@undercloud-0 ~]$ manila create --name share-02 --share-type netapp --share-network mynet nfs 20
+-----------------------------------------+----------------------------
| Property | Value +-----------------------------------------+----------------------------
| status | creating
| share_type_name | netapp
| description | None
| availability_zone | None
| share_network_id | mynet
| share_group_id | None
| revert_to_snapshot_support | True
| access_rules_status | active
| snapshot_id | None
| create_share_from_snapshot_support | True
| is_public | False
| task_state | None
| snapshot_support | False
| id | db3bedd8-bc82-4100-a65d-53ec51b5cba3
| size | 20
| source_share_group_snapshot_member_id | None
| user_id | 19f014d7b5fd43519363c5bd75da864c
| name | share-02
| share_type | abcde974-3f82-4a73-8efc-9a4f9970abab
| has_replicas | False
| replication_type | None
| created_at | 2018-09-17T16:00:07.000000
| share_proto | NFS
| mount_snapshot_support | False
| project_id | b0434b7f2c5943e797a24edd958d95e6
| metadata | {} +---------------------------------------+----------------------------
4.2.2. Listing shares and exporting information
To verify that the shares were created successfully, complete the following steps:
Run the following command:
(user) [stack@undercloud-0 ~]$ manila list
+--------------------------------------+----------+-----+-----------+ | ID | Name | ... | Status ...
+--------------------------------------+----------+-----+-----------+
| 8c3bedd8-bc82-4100-a65d-53ec51b5fe81 | share-01 | ... | available ...
+--------------------------------------+----------+-----+-----------+
Run the manila share-export-location-list command to see the share’s export locations:
(user) [stack@undercloud-0 ~]$ manila share-export-location-list share-01
+------------------------------------------------------------------
| Path
| 172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01
+------------------------------------------------------------------
4.2.3. Ensuring network connectivity to the share
The Shared File System service serves storage over networks. Therefore, compute instances intended for mounting a file share must have network connectivity to one or more of the export locations for that share.
There are many ways to configure OpenStack networking with the Shared File System service, including using network plugins as described in Networking requirements for manila.
For back ends where driver_handles_share_servers=True, a cloud user can create a share network with the details of a network to which the compute instance attaches and then reference it when creating shares.
-
For back ends where
driver_handles_share_servers=False, a cloud administrator sets up the requisite networking in advance rather than dynamically in the Shared File System back end.
-
For the CephFS via NFS back end, a cloud administrator deploys OpenStack director with isolated networks and environment arguments as documented in Installing OpenStack with CephFS via NFS and a custom network_data file to create an isolated StorageNFS network for NFS exports. After deployment, before the overcloud is used, the administrator creates a corresponding Networking service (neutron) StorageNFS shared provider network that maps to the data center’s isolated StorageNFS network.
For a compute instance to connect to this shared provider network, the user must add an additional neutron port.
To ensure network connectivity to the share, complete the following steps:
Create a security group for the StorageNFS port that allows packets to egress the port (which is required to initiate an NFS mount) but that does not allow ingress packets for 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'
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'
StorageNFSSubnet assigned IP address 172.17.5.160 to nfs-port0.
-
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, notice that the compute instance is assigned a port with the IP address 172.17.5.160 on the StorageNFS network, which can be used to mount NFS shares when access is granted to that address for the share in question.
Networking configuration on the compute instance may need to be adjusted and the services restarted for the compute instance to activate an interface with this address.
4.2.4. Granting share access
Before you can mount a share on an instance, you must grant the instance access to the share by using a command similar to the following:
# manila access-allow <SHARE> <ACCESSTYPE> --access-level <ACCESSLEVEL> <CLIENTIDENTIFIER>
Where:
-
SHARE - the share name or ID of the share created in Section 4.2.1, “Creating a share”.
ACCESSTYPE - the type of access to be requested on the share. Some types include:
ACCESSLEVEL - optional, default is rw
-
rw: read-write access to shares
-
ro: read-only access to shares
CLIENTIDENTIFIER - varies depending on ACCESSTYPE
-
Use an IP address for
ip ACCESSTYPE
-
Use CIFS user or group for
cifs ACCESSTYPE
For example:
To grant read-write access to share-01 to a compute instance with a StorageNFS network port with the IP address 172.17.5.160, run the following command:
(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
+-----------------+---------------------------------------+
| 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
+-----------------+---------------------------------------+
Access to the share has its own ID (ACCESSID).
Enter the following command to 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 | ...
+--------------+------------+--------------+--------------+---------+ ...
4.2.5. Revoking access to a share
Complete the following steps to revoke previously-granted access to a share:
Run the following command:
# manila access-deny <SHARE> <ACCESSID>
In the example command, <SHARE> can be either the share name or the share ID.
For example:
(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 | ...
+--------------+-------------+--------------+--------------+--------+
(user) [stack@undercloud-0 ~]$ manila access-deny share-01 875c6251-c17e-4c45-8516-fe0928004fff
(user) [stack@undercloud-0 ~]$ manila access-list share-01
+--------------+------------+--------------+--------------+--------+ ...
| id | access_type| access_to | access_level | state | ...
+--------------+------------+--------------+--------------+--------+ ...
+--------------+------------+--------------+--------------+--------+ ...
4.2.6. Mounting a share on an instance
After configuring the share to authenticate an instance, verify the functionality of the environment and then mount the share.
NFS client packages supporting version 4.1 must be installed on the compute instance that mounts the shares.
4.2.6.1. Verifying the environment
To verify the functionality of the environment, complete the following steps:
Run the following command to get the virtual IP (VIP) for the NFS-Ganesha service:
(user) [stack@undercloud-0 ~]$ manila share-export-location-list share-01
172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01
From the VM in which you will mount the share, ensure that the VIP is reachable via ping:
# ping 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
64 bytes from 172.17.5.13: icmp_seq=2 ttl=64 time=0.061 ms
^C
--- 172.17.5.13 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.048/0.054/0.061/0.009 ms
Verify the VIP is ready to respond to NFS rpcs on the proper port:
# rpcinfo -T tcp -a 172.17.5.13.8.1 100003 4
The IP address is written in universal address format (uaddr), which adds two extra octets (8.1) to represent the NFS service port, 2049.
4.2.6.2. Mounting the share
To mount the share from Section 4.2.1, “Creating a share” on the instance from Section 4.2.4, “Granting share access”, complete the following steps:
Log in to the instance and run the following command:
(user) [stack@undercloud-0 ~]$ openstack server ssh demo-instance0 --login root
# hostname
demo-instance0
Mount the share using the export location from Section 4.2.2, “Listing shares and exporting information”:
# mount.nfs -v 172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01 /mnt mount.nfs: timeout set for Wed Sep 19 09:14:46 2018 mount.nfs: trying text-based options 'vers=4.2,addr=172.17.5.13,clientaddr=172.17.5.160' 172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01 on /mnt type nfs
# mount | grep mnt 172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01 on /mnt type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.17.5.160,local_lock=none,addr=172.17.5.13)
To delete a share, complete the following step:
Run the following command:
# manila delete <SHARE>
In the example command, <SHARE> can be either the share name or the share ID.
For example:
# manila delete share-01
4.2.8. Disabling creation of public shares and share types through the dashboard
The dashboard allows users to set shares or share types as public during creation by using checkboxes. When creating a share, the Make visible for all checkbox sets the share as public:
The share type creation interface features a Public checkbox that does the same:
You can disable these checkboxes to limit the number of public shares and share types created by users. To do so, log in to a Controller node and add the following to /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.d/_90_manila_shares.py:
OPENSTACK_MANILA_FEATURES = {
'enable_public_shares': False
'enable_public_share_type_creation': False, }
The 'enable_public_shares':False setting disables the Make visible for all checkbox. Likewise, 'enable_public_share_type_creation':False disables the Public checkbox in the share type creation interface.
If you deployed OpenStack with High Availability, apply the same change to all Controller nodes. Then, restart the httpd service from any Controller node:
# pcs resource restart httpd-clone
Otherwise, restart the httpd service using:
# systemctl restart httpd
To view your changes, reload the dashboard. The checkboxes should no longer appear in their respective interfaces.
Disabling these checkboxes does not prevent users or OpenStack admins from setting shares or share types to public after creating them.
