This is only available on EUMETSAT side of the EWC |
Pre-requisites:
|
SFS are shared among different users and machines by using a share network. EUMETSAT clouds should already contain a pre-configured share network to use for your file shares. Verify the existence of this share networl by running the command
openstack share network list |
You should see an entry like this
Create a share network using the Manila CLI. The recommended naming convention is <tenant_name>-sfs-server
manila share-network-create --name <tenant_name>-sfs-server --description <description> |
NOT SURE IF NEUTRON NET ID IS NECESSARY. CHECK
File shares can be created using the Manila or OpenStack CLIs. First it is recommended to check what types of SFS are available in your cloud, to do that, run
openstack share type list |
which, by default, will only show the SFS type available. The output of the above command should look like. IS THIS STILL TRUE IN THE NEW CLOUD
Then create a file share with either of the following commands
openstack share create --name <share_name> --description <description> --share-type SFS --share-network <share_network> NFS <size> manila create --name <share_name> --description <description> --share-type SFS --share-network <share_network> NFS <size> |
where <share_name> is the name of the newly created share, with some optional <description> , and a type from the ones above, SFS by default. The value of <share_network_id> is the name or ID of the share network created in the previous step. Lastly <size> is the required size in GB of the file share.
To see the list of shares in the cloud run either of the commands
openstack share list manila list |
and to see the details of a specific file share, one can do
openstack share show <share_name_or_id> manila show <share_name_or_id> |
By default no VM has direct access to the newly created SFS. In order to give access to a VM with IP <instance_ip> , do
openstack share access create <share> ip <instance_ip> manila access-allow <share> ip <instance_ip> |
where <share> can the name or ID of the file share to give access to. If read-only access is required, this can be specified with the option --access-level ro . Furthermore, to give access to a range of IPs, one can use the CIDR format, e.g. 10.0.0.0/24.
One can list the IPs that have access to the share with the commands
openstack share access list <share> manila access-list <share> |
with <share> , as usual, the name or id of the share.
Access can be denied at any time with
openstack share access delete <access_id> manila access-deny myshare <access_id> |
Even if the file share is accessible to the VM, one can not read or write on it until it is mounted to a directory in the VM. In order to do so, first create an appropriate directory on the VM
mkdir <path>/<to>/<local>/<share> |
then grab the export path for the file share. This can be found by doing
openstack share show <share_name_or_id> manila show <share_name_or_id> |
under the export_locations field. It is recommended to use the path with the preferred=True keyword. An example output that has the right information can be seen here
Then mount the selected export path into the created directory
sudo mount <share_export_path> <path>/<to>/<local>/<share> |
The size of SFS is specified at the creation of the file share. However it is possible to change the size at a later time. In order to do that one can use the command
openstack share resize <share> <new_size> |
where <share> is the name or ID of the share to resize and <new_size> is the new required size in GB. Alternatively one can use the Manila CLI commands to either increase or decrease the size of a share with
manila extend <share> <new_size> manila shrink <share> <new_size> |
Note that if the new size is smaller than the original size, the resizing will fail to avoid data loss.