[User Guides] Shared File Systems Section Editing
Editing the Shared File Systems Section for the Cloud Admin Guide. 1. Reviewing the shared_file_system.rst files for sentence length, articles, and repetition. 2. Incorporating Admin User Guide content by changing file names and editing content: -cli_manage_shares.rst > shared_file_systems_manage_shares_cli.rst -dashboard_manage_shares.rst > shared_file_systems_manage_shares_dashboard.rst Change-Id: Ibe4ced6cc6ab20196c7de16b38aa9c550ffab1b2 Implements: blueprint user-guides-reorganised
This commit is contained in:
Joseph Robinson
Andreas Jaeger
parent
e8a04dc832
commit
856316c7dc
|
|
@ -5,9 +5,9 @@ Shared File Systems
|
|||
===================
|
||||
|
||||
Shared File Systems service provides a set of services for management of
|
||||
shared file systems in a multi-tenant cloud environment, similar to how
|
||||
OpenStack provides for block-based storage management through the OpenStack
|
||||
Block Storage service project. With the Shared File Systems service, you can
|
||||
shared file systems in a multi-tenant cloud environment. The service resembles
|
||||
OpenStack block-based storage management from the OpenStack Block Storage
|
||||
service project. With the Shared File Systems service, you can
|
||||
create a remote file system, mount the file system on your instances, and then
|
||||
read and write data from your instances to and from your file system.
|
||||
|
||||
|
|
@ -20,7 +20,9 @@ System (EFS) does.
|
|||
shared_file_systems_intro.rst
|
||||
shared_file_systems_key_concepts.rst
|
||||
shared_file_systems_share_management.rst
|
||||
shared_file_systems_manage_shares_cli.rst
|
||||
shared_file_systems_share_types.rst
|
||||
shared_file_systems_manage_shares_dashboard.rst
|
||||
shared_file_systems_snapshots.rst
|
||||
shared_file_systems_security_services.rst
|
||||
shared_file_systems_cgroups.rst
|
||||
|
|
|
|||
|
|
@ -16,12 +16,13 @@ consistency group.
|
|||
|
||||
.. note::
|
||||
|
||||
The **consistency groups and snapshots** are realized as an
|
||||
**experimental** Shared File Systems API in Liberty release. Contributors
|
||||
can change or remove the experimental part of the Shared File Systems API
|
||||
in further releases without maintaining backward compatibility. The
|
||||
experimental API has ``X-OpenStack-Manila-API-Experimental: true`` header
|
||||
in their HTTP requests.
|
||||
The **consistency groups and snapshots** are an **experimental**
|
||||
Shared File Systems API in the Liberty release.
|
||||
Contributors can change or remove the experimental part of the
|
||||
Shared File Systems API in further releases without maintaining
|
||||
backward compatibility. The experimental API have an
|
||||
``X-OpenStack-Manila-API-Experimental: true`` header in
|
||||
their HTTP requests.
|
||||
|
||||
Consistency groups
|
||||
------------------
|
||||
|
|
@ -38,8 +39,9 @@ Consistency groups
|
|||
|
||||
* ``false``. Consistency groups are not supported.
|
||||
|
||||
Create a new consistency group, specify a share network and one or more share
|
||||
types. In the example a consistency group ``cgroup1`` was created with
|
||||
The :command:`manila cg-create` command creates a new consistency group.
|
||||
With this command, you can specify a share network, and one or more share
|
||||
types. In the example a consistency group ``cgroup1`` was created by
|
||||
specifying two comma-separated share types:
|
||||
|
||||
.. code-block:: console
|
||||
|
|
@ -86,7 +88,7 @@ Check that consistency group is in available status:
|
|||
| name | cgroup1 |
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
To add a share to the consistency group you need to create a share with a
|
||||
To add a share to the consistency group create a share with a
|
||||
:option:`--consistency-group` option where you specify the ID of the consistency
|
||||
group in ``available`` status:
|
||||
|
||||
|
|
@ -122,9 +124,9 @@ group in ``available`` status:
|
|||
| metadata | {} |
|
||||
+-----------------------------+--------------------------------------+
|
||||
|
||||
Admin can rename the consistency group or change its description using
|
||||
:command:`manila cg-update` command, or delete it by
|
||||
:command:`manila cg-delete` command.
|
||||
Administrators can rename the consistency group, or change its
|
||||
description using :command:`manila cg-update` command. Delete the group
|
||||
with :command:`manila cg-delete` command.
|
||||
|
||||
As an administrator, you can also reset the state of a consistency group and
|
||||
force-delete a specified consistency group in any state. Use the
|
||||
|
|
@ -133,18 +135,18 @@ force-delete a specified consistency group in any state. Use the
|
|||
Use :command:`manila cg-reset-state [--state <state>] <consistency_group>`
|
||||
to update the state of a consistency group explicitly. A valid value of a
|
||||
status are ``available``, ``error``, ``creating``, ``deleting``,
|
||||
``error_deleting``. If no state is provided, available will be used.
|
||||
``error_deleting``. If no state is provided, ``available`` will be used.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ manila cg-reset-state cgroup1 --state error
|
||||
|
||||
Use :command:`manila cg-delete <consistency_group> [<consistency_group> ...]`
|
||||
to soft-delete one or more consistency group.
|
||||
to soft-delete one or more consistency groups.
|
||||
|
||||
.. note::
|
||||
|
||||
The consistency group can be deleted only if it has no dependent
|
||||
A consistency group can be deleted only if it has no dependent
|
||||
:ref:`shared_file_systems_cgsnapshots`.
|
||||
|
||||
.. code-block:: console
|
||||
|
|
@ -164,9 +166,9 @@ to force-delete a specified consistency group in any state.
|
|||
Consistency group snapshots
|
||||
---------------------------
|
||||
|
||||
You can create snapshots of consistency groups. To create a snapshot, you
|
||||
specify the ID or name of the consistency group that you want to snapshot.
|
||||
After you create a consistency group snapshot, you can create a consistency
|
||||
You can create snapshots of consistency groups. To create a snapshot,
|
||||
specify the ID or name of the consistency group. After creating a
|
||||
consistency group snapshot, it is possible to generate a consistency
|
||||
group from it.
|
||||
|
||||
Create a snapshot of consistency group ``cgroup1``:
|
||||
|
|
@ -205,13 +207,12 @@ Check the status of created consistency group snapshot:
|
|||
| description | A snapshot of the first CG. |
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
Admin can rename the consistency group snapshot or change its description
|
||||
using :command:`cg-snapshot-update` command, or delete it by
|
||||
:command:`cg-snapshot-delete`.
|
||||
Administrators can rename the consistency group snapshot, or change its
|
||||
description using the :command:`cg-snapshot-update` command, or delete
|
||||
it with the :command:`cg-snapshot-delete` command.
|
||||
|
||||
A consistency group snapshot can have ``members``. The consistency group
|
||||
snapshot members are the shares that belong to some consistency group. To add
|
||||
a member, include the :option:`--consistency-group` optional parameter in the
|
||||
A consistency group snapshot can have ``members``. To add a member,
|
||||
include the :option:`--consistency-group` optional parameter in the
|
||||
create share command. This ID must match the ID of the consistency group from
|
||||
which the consistency group snapshot was created. Then, while restoring data,
|
||||
for example, and operating with consistency group snapshots you can quickly
|
||||
|
|
@ -255,7 +256,7 @@ group from it:
|
|||
| name | cgroup2 |
|
||||
+----------------------+-----------------------------------------+
|
||||
|
||||
Check the list of consistency group. There are two groups now:
|
||||
Check the consistency group list. Two groups now appear:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -269,8 +270,8 @@ Check the list of consistency group. There are two groups now:
|
|||
+-------------------+---------+-----------------------------------------+-----------+
|
||||
|
||||
Check a list of the shares. New share with
|
||||
``ba52454e-2ea3-47fa-a683-3176a01295e6`` ID was created when you created a
|
||||
consistency group ``cgroup2`` from a snapshot with a member.
|
||||
``ba52454e-2ea3-47fa-a683-3176a01295e6`` ID appeared after the
|
||||
consistency group ``cgroup2`` was built from a snapshot with a member.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -291,7 +292,7 @@ Print detailed information about new share:
|
|||
``consistency_group_id`` fields in a new share. It has
|
||||
``source_cgsnapshot_member_id`` that is equal to the ID of the consistency
|
||||
group snapshot and ``consistency_group_id`` that is equal to the ID of
|
||||
``cgroup2`` that was created from a snapshot.
|
||||
``cgroup2`` created from a snapshot.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
|
|||
|
|
@ -4,16 +4,23 @@
|
|||
Introduction
|
||||
============
|
||||
|
||||
The OpenStack File Share service allows you to offer file-share services to
|
||||
users of an OpenStack installation. The Shared File Systems service can be
|
||||
configured to run in a single-node configuration or across multiple nodes. The
|
||||
Shared File Systems service can be configured to provision shares from one or
|
||||
more back ends, so it is required to declare at least one back end. To
|
||||
administer the Shared File Systems service, it is helpful to understand a
|
||||
number of concepts like share networks, shares, multi-tenancy and back ends
|
||||
that can be configured with the Shared File Systems service. The Shared File
|
||||
Systems service consists of three types of services, which are similar to
|
||||
those of the Block Storage service:
|
||||
The OpenStack File Share service allows you to offer shared file systems
|
||||
service to OpenStack users in your installation. The Shared File Systems
|
||||
service can run in a single-node or multiple node configuration.
|
||||
The Shared File Systems service can be configured to provision shares
|
||||
from one or more back ends, so it is required to declare at least one
|
||||
back end. Shared File System service contains several configurable
|
||||
components.
|
||||
|
||||
It is important to understand these components:
|
||||
|
||||
* Share networks
|
||||
* Shares
|
||||
* Multi-tenancy
|
||||
* Back ends
|
||||
|
||||
The Shared File Systems service consists of three types of services,
|
||||
which are similar to those of the Block Storage service:
|
||||
|
||||
- ``manila-api``
|
||||
- ``manila-scheduler``
|
||||
|
|
|
|||
|
|
@ -9,9 +9,9 @@ Share
|
|||
|
||||
In the Shared File Systems service ``share`` is the fundamental resource unit
|
||||
allocated by the Shared File System service. It represents an allocation of a
|
||||
persistent, readable, and writable filesystem that can be accessed by
|
||||
OpenStack compute instances, or clients outside of OpenStack, which depends on
|
||||
deployment configuration.
|
||||
persistent, readable, and writable filesystem. Compute instances access these
|
||||
filesystems. Depending on the deployment configuration, clients outside of
|
||||
OpenStack can also access the filesystem.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -22,18 +22,18 @@ deployment configuration.
|
|||
Snapshot
|
||||
~~~~~~~~
|
||||
|
||||
A ``snapshot`` is a point-in-time, read-only copy of a ``share``.
|
||||
``Snapshots`` can be created from an existing ``share`` that is operational
|
||||
regardless of whether a client has mounted the file system. A ``snapshot``
|
||||
A ``snapshot`` is a point-in-time, read-only copy of a ``share``. You can
|
||||
create ``Snapshots`` from an existing, operational ``share`` regardless
|
||||
of whether a client has mounted the file system. A ``snapshot``
|
||||
can serve as the content source for a new ``share`` when the ``share``
|
||||
is created with the create from snapshot option specified.
|
||||
|
||||
Storage Pools
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
With the Kilo release of OpenStack, the Shared File Systems service has
|
||||
introduced the concept of ``storage pools``. The storage may present one or
|
||||
more logical storage resource pools from which the Shared File Systems service
|
||||
With the Kilo release of OpenStack, Shared File Systems can use
|
||||
``storage pools``. The storage may present one or more logical storage
|
||||
resource pools from which the Shared File Systems service
|
||||
will select as a storage location when provisioning ``shares``.
|
||||
|
||||
Share Type
|
||||
|
|
@ -41,58 +41,60 @@ Share Type
|
|||
|
||||
``Share type`` is an abstract collection of criteria used to characterize
|
||||
``shares``. They are most commonly used to create a hierarchy of functional
|
||||
capabilities that represent a tiered level of storage services; for example, a
|
||||
cloud administrator might define a premium ``share type`` that indicates a
|
||||
greater level of performance than a basic ``share type``, which would
|
||||
represent a best-effort level of performance.
|
||||
capabilities. This hierarchy represents tiered storage services levels. For
|
||||
example, a cloud administrator might define a premium ``share type`` that
|
||||
indicates a greater level of performance than a basic ``share type``.
|
||||
Premium represents the best performance level.
|
||||
|
||||
|
||||
Share Access Rules
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
``Share access rules`` define which users can access a particular ``share``.
|
||||
For example, access rules can be declared for NFS shares by listing the valid
|
||||
IP networks, in CIDR notation, which should have access to the ``share``.
|
||||
For example, cloud administrators can declare rules for NFS shares by
|
||||
listing the valid IP networks which will access the ``share``. List the
|
||||
IP networks in CIDR notation.
|
||||
|
||||
Security Services
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
``Security services`` are the concept in the Shared File Systems service that
|
||||
allow Finer-grained client access rules to be declared for authentication or
|
||||
``Security services``allow granular client access rules for cloud
|
||||
administrators. They can declare rules for authentication or
|
||||
authorization to access ``share`` content. External services including LDAP,
|
||||
Active Directory, Kerberos can be declared as resources that should be
|
||||
consulted when making an access decision to a particular ``share``. ``Shares``
|
||||
can be associated to multiple security services but only one service per one
|
||||
type.
|
||||
Active Directory, Kerberos can be declared as resources. Examine and consult
|
||||
these resources when making an access decision for a particular ``share``.
|
||||
You can associate ``Shares`` with multiple security services, but only one
|
||||
service per one type.
|
||||
|
||||
Share Networks
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
A ``share network`` is an object that defines a relationship between a
|
||||
tenant's network and subnet, as defined in an OpenStack Networking service or
|
||||
Compute service, and the ``shares`` created by the same tenant; that is, a
|
||||
tenant may find it desirable to provision ``shares`` such that only instances
|
||||
connected to a particular OpenStack-defined network have access to the
|
||||
``share``. Also, ``security services`` can be attached to ``share networks``,
|
||||
Compute service. The ``share network`` is also defined in ``shares``
|
||||
created by the same tenant. A tenant may find it desirable to
|
||||
provision ``shares`` such that only instances connected to a particular
|
||||
OpenStack-defined network have access to the ``share``. Also,
|
||||
``security services`` can be attached to ``share networks``,
|
||||
because most of auth protocols require some interaction with network services.
|
||||
|
||||
The Shared File Systems service has the ability to work outside of OpenStack.
|
||||
That is due to the ``StandaloneNetworkPlugin`` that can be used with any
|
||||
network platform and does not require some specific network services in
|
||||
That is due to the ``StandaloneNetworkPlugin``. The plugin is compatible with
|
||||
any network platform, and does not require specific network services in
|
||||
OpenStack like Compute or Networking service. You can set the network
|
||||
parameters in its configuration file.
|
||||
parameters in the ``manila.conf`` file.
|
||||
|
||||
Share Servers
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
A ``share server`` is a logical entity that hosts the shares that are
|
||||
created on a specific ``share network``. A ``share server`` may be a
|
||||
A ``share server`` is a logical entity that hosts the shares created
|
||||
on a specific ``share network``. A ``share server`` may be a
|
||||
configuration object within the storage controller, or it may represent
|
||||
logical resources provisioned within an OpenStack deployment that are used to
|
||||
logical resources provisioned within an OpenStack deployment used to
|
||||
support the data path used to access ``shares``.
|
||||
|
||||
``Share servers`` interact with network services to determine the appropriate
|
||||
IP addresses on which to export ``shares`` according to the related ``share
|
||||
network``. The Shared File Systems service has a pluggable network model that
|
||||
allows ``share servers`` to work with different implementations of Network
|
||||
service.
|
||||
allows ``share servers`` to work with different implementations of
|
||||
the Networking service.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,35 @@
|
|||
.. _share_migration:
|
||||
|
||||
==============
|
||||
Migrate shares
|
||||
==============
|
||||
|
||||
As an administrator, you can migrate a share with its data from one
|
||||
location to another in a manner that is transparent to users and
|
||||
workloads. You can use ``manila`` client commands to complete a share
|
||||
migration.
|
||||
|
||||
Possible use cases for data migration include:
|
||||
|
||||
- Bring down a physical storage device for maintenance without
|
||||
disrupting workloads.
|
||||
|
||||
- Modify the properties of a share.
|
||||
|
||||
- Free up space in a thinly-provisioned back end.
|
||||
|
||||
Migrate a share with the :command:`manila migrate` command, as shown in the
|
||||
following example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ manila migrate shareID destinationHost --force-host-copy True|False
|
||||
|
||||
In this example, :option:`--force-host-copy True` forces the generic
|
||||
host-based migration mechanism and bypasses any driver optimizations.
|
||||
``destinationHost`` is in this format ``host#pool`` which includes
|
||||
destination host and pool.
|
||||
|
||||
.. note::
|
||||
|
||||
If the user is not an administrator, the migration fails.
|
||||
|
|
@ -0,0 +1,149 @@
|
|||
=============================
|
||||
Manage shares and share types
|
||||
=============================
|
||||
|
||||
Shares are file storage that instances can access. Users can
|
||||
allow or deny a running instance to have access to a share at any time.
|
||||
For information about using the dashboard to create and manage shares as
|
||||
an end user, see the
|
||||
`OpenStack End User Guide <http://docs.openstack.org/user-guide/dashboard_manage_shares.html>`_.
|
||||
|
||||
As an administrative user, you can manage shares and share types for users
|
||||
in various projects. You can create and delete share types, and view
|
||||
or delete shares.
|
||||
|
||||
.. _create-a-share-type:
|
||||
|
||||
Create a share type
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and choose the :guilabel:`admin`
|
||||
project from the drop-down list at the top of the page.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Shares` category.
|
||||
|
||||
#. Click the :guilabel:`Share Types` tab, and click
|
||||
:guilabel:`Create Share Type` button. In the
|
||||
:guilabel:`Create Share Type` window, enter or select the
|
||||
following values.
|
||||
|
||||
:guilabel:`Name`: Enter a name for the share type.
|
||||
|
||||
:guilabel:`Driver handles share servers`: Choose True or False
|
||||
|
||||
:guilabel:`Extra specs`: To add extra specs, use key=value.
|
||||
|
||||
#. Click :guilabel:`Create Share Type` button to confirm your changes.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
||||
Update share type
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and choose the :guilabel:`admin` project from
|
||||
the drop-down list at the top of the page.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Shares` category.
|
||||
|
||||
#. Click the :guilabel:`Share Types` tab, select the share type
|
||||
that you want to update.
|
||||
|
||||
#. Select :guilabel:`Update Share Type` from Actions.
|
||||
|
||||
#. In the :guilabel:`Update Share Type` window, update extra specs.
|
||||
|
||||
:guilabel:`Extra specs`: To add extra specs, use key=value.
|
||||
To unset extra specs, use key.
|
||||
|
||||
#. Click :guilabel:`Update Share Type` button to confirm your changes.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
||||
Delete share types
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When you delete a share type, shares of that type are not deleted.
|
||||
|
||||
#. Log in to the dashboard and choose the :guilabel:`admin` project from
|
||||
the drop-down list at the top of the page.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Shares` category.
|
||||
|
||||
#. Click the :guilabel:`Share Types` tab, select the share type
|
||||
or types that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Share Types` button.
|
||||
|
||||
#. In the :guilabel:`Confirm Delete Share Types` window, click the
|
||||
:guilabel:`Delete Share Types` button to confirm the action.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
||||
Delete shares
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and choose the :guilabel:`admin` project
|
||||
from the drop-down list at the top of the page.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Shares` category.
|
||||
|
||||
#. Select the share or shares that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Shares` button.
|
||||
|
||||
#. In the :guilabel:`Confirm Delete Shares` window, click the
|
||||
:guilabel:`Delete Shares` button to confirm the action.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
||||
Delete share server
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and choose the :guilabel:`admin` project
|
||||
from the drop-down list at the top of the page.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Share Servers` category.
|
||||
|
||||
#. Select the share that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Share Server` button.
|
||||
|
||||
#. In the :guilabel:`Confirm Delete Share Server` window, click the
|
||||
:guilabel:`Delete Share Server` button to confirm the action.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
||||
Delete share networks
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and choose the :guilabel:`admin` project
|
||||
from the drop-down list at the top of the page.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Share Networks` category.
|
||||
|
||||
#. Select the share network or share networks that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Share Networks` button.
|
||||
|
||||
#. In the :guilabel:`Confirm Delete Share Networks` window, click the
|
||||
:guilabel:`Delete Share Networks` button to confirm the action.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
|
@ -5,14 +5,14 @@ Multi-storage configuration
|
|||
===========================
|
||||
|
||||
The Shared File Systems service can provide access to multiple file storage
|
||||
back ends. In general, the workflow with multiple back ends looks very similar
|
||||
back ends. In general, the workflow with multiple back ends looks similar
|
||||
to the Block Storage service one, see :ref:`Configure multiple-storage back
|
||||
ends in Openstack Block Storage service <multi_backend>`.
|
||||
|
||||
Using ``manila.conf``, you can spawn multiple share services. To do it, you
|
||||
should set the `enabled_share_backends` flag in the ``manila.conf`` file. This
|
||||
flag defines the comma-separated names of the configuration stanzas for the
|
||||
different back ends: one name is associated to one configuration group for a
|
||||
different back ends. One name is associated to one configuration group for a
|
||||
back end.
|
||||
|
||||
The following example runs three configured share services:
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ Networking
|
|||
==========
|
||||
|
||||
Unlike the OpenStack Block Storage service, the Shared File Systems service
|
||||
requires interaction with the Networking service. First of all, it is because
|
||||
must connect to the Networking service. First of all, it is because
|
||||
the share services require the option to self-manage share servers. Also, for
|
||||
authentication and authorization of the clients, the Shared File Systems
|
||||
service can be optionally configured to work with different network
|
||||
|
|
|
|||
|
|
@ -4,12 +4,12 @@
|
|||
Security services
|
||||
=================
|
||||
|
||||
A security service stores configuration information for clients for
|
||||
A security service stores client configuration information used for
|
||||
authentication and authorization (AuthN/AuthZ). For example, a share server
|
||||
will be the client for an existing service such as LDAP, Kerberos, or
|
||||
Microsoft Active Directory.
|
||||
|
||||
You can associate a share with from one to three security service types:
|
||||
You can associate a share with one to three security service types:
|
||||
|
||||
- ``ldap``. LDAP.
|
||||
|
||||
|
|
@ -29,13 +29,14 @@ You can configure a security service with these options:
|
|||
|
||||
- The password for the user, if you specify a user name.
|
||||
|
||||
The security service can be added to the
|
||||
You can add the security service to the
|
||||
:ref:`share network <shared_file_systems_share_networks>`.
|
||||
|
||||
To create a security service, specify the security service type and optionally
|
||||
name, description of a security service, DNS IP address used inside tenant's
|
||||
To create a security service, specify the security service type, a
|
||||
description of a security service, DNS IP address used inside tenant's
|
||||
network, security service IP address or host name, domain, security
|
||||
service user or group used by tenant, a password of user.
|
||||
service user or group used by tenant, and a password for the user. The
|
||||
share name is optional.
|
||||
|
||||
Create a ``ldap`` security service:
|
||||
|
||||
|
|
@ -100,13 +101,14 @@ To see the list of created security service use
|
|||
+--------------------------------------+------------------------------+--------+----------+
|
||||
|
||||
You can add a security service to the existing
|
||||
:ref:`share network <shared_file_systems_share_networks>` that is not used yet
|
||||
(is not associated with a share).
|
||||
:ref:`share network <shared_file_systems_share_networks>`, which is not
|
||||
yet used (a ``share network`` not associated with a share).
|
||||
|
||||
Add a security service to the share network with
|
||||
``share-network-security-service-add`` specifying share network, security
|
||||
service and print the information about the security service. You can see
|
||||
new attribute ``share_networks`` with associated share network ID.
|
||||
``share-network-security-service-add`` specifying share network and
|
||||
security service. The command returns information about the
|
||||
security service. You can see view new attributes and ``share_networks``
|
||||
using the associated share network ID.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -133,8 +135,9 @@ new attribute ``share_networks`` with associated share network ID.
|
|||
| description | None |
|
||||
+----------------+-------------------------------------------+
|
||||
|
||||
It is possible to see the list of security services associated with
|
||||
given share network. List security services for ``share_net2`` share network:
|
||||
It is possible to see the list of security services associated
|
||||
with a given share network. List security services for ``share_net2``
|
||||
share network with:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -147,7 +150,8 @@ given share network. List security services for ``share_net2`` share network:
|
|||
+--------------------------------------+--------------------------+--------+------+
|
||||
|
||||
You also can dissociate a security service from the share network
|
||||
and see that a security service now has empty list of share networks:
|
||||
and confirm that the security service now has an empty list of
|
||||
share networks:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -174,13 +178,13 @@ and see that a security service now has empty list of share networks:
|
|||
| description | None |
|
||||
+----------------+--------------------------------------+
|
||||
|
||||
Shared File Systems service allows you to update a security service fields
|
||||
The Shared File Systems service allows you to update a security service field
|
||||
using :command:`manila security-service-update` command with optional
|
||||
arguments such as :option:`--dns-ip`, :option:`--server`, :option:`--domain`,
|
||||
:option:`--user`, :option:`--password`, :option:`--name`, or
|
||||
:option:`--description`.
|
||||
|
||||
To remove a security service, that is not associated with any share networks,
|
||||
To remove a security service not associated with any share networks
|
||||
run:
|
||||
|
||||
.. code-block:: console
|
||||
|
|
|
|||
|
|
@ -23,18 +23,17 @@ To create a share type, use :command:`manila type-create` command as:
|
|||
where the ``name`` is the share type name, ``--is_public`` defines the level of
|
||||
the visibility for the share type, ``snapshot_support`` and
|
||||
``spec_driver_handles_share_servers`` are the extra specifications used to
|
||||
filter back ends.
|
||||
Administrators can create share types with these extra specifications that are
|
||||
used for the back ends filtering:
|
||||
filter back ends. Administrators can create share types with these extra
|
||||
specifications for the back ends filtering:
|
||||
|
||||
- ``driver_handles_share_servers``. Required. Defines the driver mode for share
|
||||
server life cycle management. Valid values are ``true``/``1`` and
|
||||
``false``/``0``.
|
||||
Set to True when the share driver can manage, or handle, the share server
|
||||
life cycle.
|
||||
Set to False when an administrator rather than a share driver manages the
|
||||
bare metal storage with some net interface instead of the presence of the
|
||||
share servers.
|
||||
Set to False when an administrator, rather than a share driver, manages
|
||||
the bare metal storage with some net interface instead of the presence
|
||||
of the share servers.
|
||||
|
||||
- ``snapshot_support``. Filters back ends by whether they do or do not support
|
||||
share snapshots. Default is ``True``.
|
||||
|
|
@ -49,16 +48,16 @@ used for the back ends filtering:
|
|||
Administrators can also set additional extra specifications for a share type
|
||||
for the following purposes:
|
||||
|
||||
- *Filter back ends*. Unqualified extra specifications that are written in
|
||||
- *Filter back ends*. Unqualified extra specifications written in
|
||||
this format: ``extra_spec=value``. For example, **netapp_raid_type=raid4**.
|
||||
|
||||
- *Set data for the driver*. Qualified extra specifications that are written
|
||||
always with the prefix with a colon, except for the special ``capabilities``
|
||||
- *Set data for the driver*. Qualified extra specifications always written
|
||||
with the prefix with a colon, except for the special ``capabilities``
|
||||
prefix, in this format: ``vendor:extra_spec=value``. For example,
|
||||
**netapp:thin_provisioned=true**.
|
||||
|
||||
The scheduler uses the special capabilities prefix for filtering. The scheduler
|
||||
can only create a share on a back end that reports capabilities that match the
|
||||
can only create a share on a back end that reports capabilities matching the
|
||||
un-scoped extra-spec keys for the share type. For details, see `Capabilities
|
||||
and Extra-Specs <http://docs.openstack.org/developer/manila/devref/
|
||||
capabilities_and_extra_specs.html>`_.
|
||||
|
|
@ -77,9 +76,9 @@ default a share type is created as publicly accessible. Set
|
|||
Share type operations
|
||||
---------------------
|
||||
|
||||
To create a new share type you need to specify name of new share type and
|
||||
required extra spec ``driver_handles_share_servers``. Also, the new share type
|
||||
can be public.
|
||||
To create a new share type you need to specify the name of the new share
|
||||
type. You also require an extra spec ``driver_handles_share_servers``.
|
||||
The new share type can also be public.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -96,14 +95,14 @@ can be public.
|
|||
You can set or unset extra specifications for a share type
|
||||
using **manila type-key <share_type> set <key=value>** command. Since it is up
|
||||
to each driver what extra specification keys it uses, see the documentation
|
||||
for a specified driver.
|
||||
for the specified driver.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ manila type-key netapp1 set thin_provisioned=True
|
||||
|
||||
It is also possible for administrator to see a list of current share types and
|
||||
extra specifications:
|
||||
It is also possible to view a list of current share types and extra
|
||||
specifications:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -120,7 +119,7 @@ extra specifications:
|
|||
Use :command:`manila type-key <share_type> unset <key>` to unset an extra
|
||||
specification.
|
||||
|
||||
The public or private share type can be deleted by means of
|
||||
The public or private share type can be deleted with the
|
||||
:command:`manila type-delete <share_type>` command.
|
||||
|
||||
.. _share_type_access:
|
||||
|
|
@ -128,9 +127,9 @@ The public or private share type can be deleted by means of
|
|||
Share type access
|
||||
-----------------
|
||||
|
||||
You can manage the access to the private share type for the different projects:
|
||||
add access, remove access, and get information about access for a specified
|
||||
private share type.
|
||||
You can manage access to a private share type for different projects.
|
||||
Administrators can provide access, remove access, and retrieve
|
||||
information about access for a specified private share.
|
||||
|
||||
Create a private type:
|
||||
|
||||
|
|
@ -146,8 +145,8 @@ Create a private type:
|
|||
|
||||
.. note::
|
||||
|
||||
If you run :command:`manila type-list` you see only public types.
|
||||
To see the private types also, run :command:`manila type-list` with
|
||||
If you run :command:`manila type-list` only public share types appear.
|
||||
To see private share types, run :command:`manila type-list` with
|
||||
:option:`-all` optional argument.
|
||||
|
||||
Grant access to created private type for a demo and alt_demo projects
|
||||
|
|
@ -158,7 +157,7 @@ by providing their IDs:
|
|||
$ manila type-access-add my_type1 d8f9af6915404114ae4f30668a4f5ba7
|
||||
$ manila type-access-add my_type1 e4970f57f1824faab2701db61ee7efdf
|
||||
|
||||
Get information about access for a private share type ``my_type1``:
|
||||
To view information about access for a private share, type ``my_type1``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -171,9 +170,9 @@ Get information about access for a private share type ``my_type1``:
|
|||
| e4970f57f1824faab2701db61ee7efdf |
|
||||
+----------------------------------+
|
||||
|
||||
After you granted the access to the share type users that belong to project
|
||||
with granted access can see the type in the list and create shares with
|
||||
allowed private share type.
|
||||
After granting access to the share, the target project
|
||||
can see the share type in the list, and create private
|
||||
shares.
|
||||
|
||||
To deny access for a specified project, use
|
||||
:command:`manila type-access-remove <share_type> <project_id>` command.
|
||||
|
|
|
|||
|
|
@ -7,11 +7,12 @@ Share snapshots
|
|||
The Shared File Systems service provides a snapshot mechanism to help users
|
||||
restore data by running the :command:`manila snapshot-create` command.
|
||||
|
||||
To export a snapshot, you can create shares from it, then mount new share to
|
||||
instance and then directly copy files from attached share into archive.
|
||||
To export a snapshot, create a share from it, then mount the new share
|
||||
to an instance. Copy files from the attached share into the archive.
|
||||
|
||||
To import a snapshot, create a new share with appropriate size, attach it to
|
||||
instance and then copy file from archive to attached file system.
|
||||
instance, and then copy a file from the archive to the attached file
|
||||
system.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -37,7 +38,7 @@ Create a snapshot from the share:
|
|||
| description | Snapshot of Share1 |
|
||||
+-------------+--------------------------------------+
|
||||
|
||||
Update name or description of a snapshot if it is needed:
|
||||
Update snapshot name or description if needed:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -63,9 +64,10 @@ Check that status of a snapshot is ``available``:
|
|||
| description | Snapshot of Share1 |
|
||||
+-------------+--------------------------------------+
|
||||
|
||||
To restore your data from snapshot, use :command:`manila create` with key
|
||||
:option:`--snapshot-id`. This creates a new share from exiting snapshot.
|
||||
Create a share from a snapshot and check whether it is available:
|
||||
To restore your data from a snapshot, use :command:`manila create` with
|
||||
key :option:`--snapshot-id`. This creates a new share from an
|
||||
existing snapshot. Create a share from a snapshot and check whether
|
||||
it is available:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
|
@ -129,13 +131,14 @@ Create a share from a snapshot and check whether it is available:
|
|||
+-----------------------------+-------------------------------------------+
|
||||
|
||||
You can soft-delete a snapshot using :command:`manila snapshot-delete
|
||||
<snapshot_name_or_ID>`. If a snapshot is in busy state and during deleting
|
||||
got the ``error_deleting`` status, administrator can force-delete it or
|
||||
explicitly reset the state.
|
||||
<snapshot_name_or_ID>`. If a snapshot is in busy state, and during
|
||||
the delete an ``error_deleting`` status appeared, administrator can
|
||||
force-delete it or explicitly reset the state.
|
||||
|
||||
Use :command:`snapshot-reset-state [--state <state>] <snapshot>` to update
|
||||
the state of a snapshot explicitly. A valid value of a status are
|
||||
``available``, ``error``, ``creating``, ``deleting``, ``error_deleting``.
|
||||
If no state is provided, available will be used.
|
||||
If no state is provided, the ``available`` state will be used.
|
||||
|
||||
Use :command:`manila snapshot-force-delete <snapshot>` to force-delete
|
||||
a specified share snapshot in any state.
|
||||
|
|
|
|||
Loading…
Reference in New Issue