User Guide Identity and Shared File Systems chapters - Reorganization and Edit
1.) This patch edits several files in the Identity and Shared File Systems chapters of the
Cloud Admin Guide for word choice and clarity as a part of the User Guide Reorg.
2.) This patch also reorganizes two small identity service files that
provide information on specic features into a
single file headed by a keystone service useage example.
The new file can contain small feature additions in future
releases, keeping them in a single file to prevent the Admin Guide content becoming disorganised.
Change-Id: I0699e500cdd98183de1d8964ab92cc6e3b693e02
Implements: blueprint user-guides-reorganised
This commit is contained in:
Joseph Robinson
parent
d920254be2
commit
ae1ac53d49
@ -4,11 +4,11 @@ Identity concepts
|
||||
|
||||
Authentication
|
||||
The process of confirming the identity of a user. To confirm an incoming
|
||||
request, OpenStack Identity validates a set of credentials that the user
|
||||
supplies. Initially, these credentials are a user name and password or a
|
||||
request, OpenStack Identity validates a set of credentials users
|
||||
supply. Initially, these credentials are a user name and password, or a
|
||||
user name and API key. When OpenStack Identity validates user credentials,
|
||||
it issues an authentication token that the user provides in subsequent
|
||||
requests.
|
||||
it issues an authentication token. Users provide the token in
|
||||
subsequent requests.
|
||||
|
||||
Credentials
|
||||
Data that confirms the identity of the user. For example, user
|
||||
@ -16,10 +16,10 @@ Credentials
|
||||
token that the Identity service provides.
|
||||
|
||||
Domain
|
||||
An Identity service API v3 entity. Represents a collection of
|
||||
projects and users that defines administrative boundaries for the
|
||||
management of Identity entities. A domain, which can represent an
|
||||
individual, company, or operator-owned space, exposes
|
||||
An Identity service API v3 entity. Domains are a collection of
|
||||
projects and users that define administrative boundaries for
|
||||
managing Identity entities. Domains can represent an
|
||||
individual, company, or operator-owned space. They expose
|
||||
administrative activities directly to system users. Users can be
|
||||
granted the administrator role for a domain. A domain
|
||||
administrator can create projects, users, and groups in a domain
|
||||
@ -32,18 +32,18 @@ Endpoint
|
||||
all consumable services that are available across the regions.
|
||||
|
||||
Group
|
||||
An Identity service API v3 entity. Represents a collection of
|
||||
users that are owned by a domain. A group role granted to a domain
|
||||
or project applies to all users in the group. Adding users to, or
|
||||
removing users from, a group respectively grants, or revokes,
|
||||
their role and authentication to the associated domain or project.
|
||||
An Identity service API v3 entity. Groups are a collection of
|
||||
users owned by a domain. A group role, granted to a domain
|
||||
or project, applies to all users in the group. Adding or removing
|
||||
users to or from a group grants or revokes their role and
|
||||
authentication to the associated domain or project.
|
||||
|
||||
OpenStackClient
|
||||
A command-line interface for several OpenStack services including
|
||||
the Identity API. For example, a user can run the
|
||||
:command:`openstack service create` and
|
||||
:command:`openstack endpoint create` commands to register services
|
||||
in her OpenStack installation.
|
||||
in their OpenStack installation.
|
||||
|
||||
Project
|
||||
A container that groups or isolates resources or identity objects.
|
||||
@ -60,8 +60,8 @@ Region
|
||||
Role
|
||||
A personality with a defined set of user rights and privileges to
|
||||
perform a specific set of operations. The Identity service issues
|
||||
a token that includes a list of roles to a user. When a user calls
|
||||
a service, that service interprets the set of user roles and
|
||||
a token to a user that includes a list of roles. When a user calls
|
||||
a service, that service interprets the user role set, and
|
||||
determines to which operations or resources each role grants
|
||||
access.
|
||||
|
||||
|
||||
@ -1,32 +0,0 @@
|
||||
=============
|
||||
Example usage
|
||||
=============
|
||||
|
||||
The ``keystone`` client is set up to expect commands in the general
|
||||
form of ``keystone command argument``, followed by flag-like keyword
|
||||
arguments to provide additional (often optional) information. For
|
||||
example, the :command:`user-list` and :command:`tenant-create`
|
||||
commands can be invoked as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Using token auth env variables
|
||||
export OS_SERVICE_ENDPOINT=http://127.0.0.1:5000/v2.0/
|
||||
export OS_SERVICE_TOKEN=secrete_token
|
||||
keystone user-list
|
||||
keystone tenant-create --name demo
|
||||
|
||||
# Using token auth flags
|
||||
keystone --os-token secrete --os-endpoint http://127.0.0.1:5000/v2.0/ user-list
|
||||
keystone --os-token secrete --os-endpoint http://127.0.0.1:5000/v2.0/ tenant-create --name=demo
|
||||
|
||||
# Using user + password + project_name env variables
|
||||
export OS_USERNAME=admin
|
||||
export OS_PASSWORD=secrete
|
||||
export OS_PROJECT_NAME=admin
|
||||
openstack user list
|
||||
openstack project create demo
|
||||
|
||||
# Using user + password + project-name flags
|
||||
openstack --os-username admin --os-password secrete --os-project-name admin user list
|
||||
openstack --os-username admin --os-password secrete --os-project-name admin project create demo
|
||||
@ -0,0 +1,82 @@
|
||||
|
||||
Example usage and Identity features
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The ``keystone`` client is set up to expect commands in the general
|
||||
form of ``keystone command argument``, followed by flag-like keyword
|
||||
arguments to provide additional (often optional) information. For
|
||||
example, the :command:`user-list` and :command:`tenant-create`
|
||||
commands can be invoked as follows:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
# Using token auth env variables
|
||||
export OS_SERVICE_ENDPOINT=http://127.0.0.1:5000/v2.0/
|
||||
export OS_SERVICE_TOKEN=secrete_token
|
||||
keystone user-list
|
||||
keystone tenant-create --name demo
|
||||
|
||||
# Using token auth flags
|
||||
keystone --os-token secrete --os-endpoint http://127.0.0.1:5000/v2.0/ user-list
|
||||
keystone --os-token secrete --os-endpoint http://127.0.0.1:5000/v2.0/ tenant-create --name=demo
|
||||
|
||||
# Using user + password + project_name env variables
|
||||
export OS_USERNAME=admin
|
||||
export OS_PASSWORD=secrete
|
||||
export OS_PROJECT_NAME=admin
|
||||
openstack user list
|
||||
openstack project create demo
|
||||
|
||||
# Using user + password + project-name flags
|
||||
openstack --os-username admin --os-password secrete --os-project-name admin user list
|
||||
openstack --os-username admin --os-password secrete --os-project-name admin project create demo
|
||||
|
||||
|
||||
Logging
|
||||
-------
|
||||
|
||||
You configure logging externally to the rest of Identity. The name of
|
||||
the file specifying the logging configuration is set using the
|
||||
``log_config`` option in the ``[DEFAULT]`` section of the
|
||||
``keystone.conf`` file. To route logging through syslog, set
|
||||
``use_syslog=true`` in the ``[DEFAULT]`` section.
|
||||
|
||||
A sample logging configuration file is available with the project in
|
||||
``etc/logging.conf.sample``. Like other OpenStack projects, Identity
|
||||
uses the Python logging module, which provides extensive configuration
|
||||
options that let you define the output levels and formats.
|
||||
|
||||
|
||||
User CRUD
|
||||
---------
|
||||
|
||||
Identity provides a user CRUD (Create, Read, Update, and Delete) filter that
|
||||
Administrators can add to the ``public_api`` pipeline. The user CRUD filter
|
||||
enables users to use a HTTP PATCH to change their own password. To enable
|
||||
this extension you should define a ``user_crud_extension`` filter, insert
|
||||
it after the ``*_body`` middleware and before the ``public_service``
|
||||
application in the ``public_api`` WSGI pipeline in
|
||||
``keystone-paste.ini``. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[filter:user_crud_extension]
|
||||
paste.filter_factory = keystone.contrib.user_crud:CrudExtension.factory
|
||||
|
||||
[pipeline:public_api]
|
||||
pipeline = sizelimit url_normalize request_id build_auth_context token_auth admin_token_auth json_body ec2_extension user_crud_extension public_service
|
||||
|
||||
Each user can then change their own password with a HTTP PATCH.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ curl -X PATCH http://localhost:5000/v2.0/OS-KSCRUD/users/USERID -H "Content-type: application/json" \
|
||||
-H "X_Auth_Token: AUTHTOKENID" -d '{"user": {"password": "ABCD", "original_password": "DCBA"}}'
|
||||
|
||||
In addition to changing their password, all current tokens for the user
|
||||
are invalidated.
|
||||
|
||||
.. note::
|
||||
|
||||
Only use a KVS back end for tokens when testing.
|
||||
|
||||
@ -1,14 +0,0 @@
|
||||
=======
|
||||
Logging
|
||||
=======
|
||||
|
||||
You configure logging externally to the rest of Identity. The name of
|
||||
the file specifying the logging configuration is set using the
|
||||
``log_config`` option in the ``[DEFAULT]`` section of the
|
||||
``keystone.conf`` file. To route logging through syslog, set
|
||||
``use_syslog=true`` in the ``[DEFAULT]`` section.
|
||||
|
||||
A sample logging configuration file is available with the project in
|
||||
``etc/logging.conf.sample``. Like other OpenStack projects, Identity
|
||||
uses the Python logging module, which provides extensive configuration
|
||||
options that let you define the output levels and formats.
|
||||
@ -24,10 +24,8 @@ command-line client.
|
||||
keystone_fernet_token_faq.rst
|
||||
keystone_use_trusts.rst
|
||||
keystone_caching_layer.rst
|
||||
identity_user_crud.rst
|
||||
identity_logging.rst
|
||||
identity_start.rst
|
||||
identity_example_usage.rst
|
||||
identity_keystone_usage_and_features.rst
|
||||
identity_auth_token_middleware.rst
|
||||
identity_service_api_protection.rst
|
||||
identity_troubleshoot.rst
|
||||
|
||||
@ -1,32 +0,0 @@
|
||||
=========
|
||||
User CRUD
|
||||
=========
|
||||
|
||||
Identity provides a user CRUD (Create, Read, Update, and Delete) filter that
|
||||
can be added to the ``public_api`` pipeline. The user CRUD filter enables users
|
||||
to use a HTTP PATCH to change their own password. To enable this extension you
|
||||
should define a ``user_crud_extension`` filter, insert it after the ``*_body``
|
||||
middleware and before the ``public_service`` application in the ``public_api``
|
||||
WSGI pipeline in ``keystone-paste.ini``. For example:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[filter:user_crud_extension]
|
||||
paste.filter_factory = keystone.contrib.user_crud:CrudExtension.factory
|
||||
|
||||
[pipeline:public_api]
|
||||
pipeline = sizelimit url_normalize request_id build_auth_context token_auth admin_token_auth json_body ec2_extension user_crud_extension public_service
|
||||
|
||||
Each user can then change their own password with a HTTP PATCH.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ curl -X PATCH http://localhost:5000/v2.0/OS-KSCRUD/users/USERID -H "Content-type: application/json" \
|
||||
-H "X_Auth_Token: AUTHTOKENID" -d '{"user": {"password": "ABCD", "original_password": "DCBA"}}'
|
||||
|
||||
In addition to changing their password, all current tokens for the user
|
||||
are invalidated.
|
||||
|
||||
.. note::
|
||||
|
||||
Only use a KVS back end for tokens when testing.
|
||||
@ -6,9 +6,9 @@ Consistency groups
|
||||
|
||||
Consistency groups enable you to create snapshots from multiple file system
|
||||
shares at the same point in time. For example, a database might place its
|
||||
tables, logs, and configuration on separate shares. To restore this database
|
||||
from a previous point in time, it makes sense to restore the logs, tables, and
|
||||
configuration together from the exact same point in time.
|
||||
tables, logs, and configurations on separate shares. Store logs, tables,
|
||||
and configurations at the same point in time to effectively restore a
|
||||
database.
|
||||
|
||||
The Shared File System service allows you to create a snapshot of the
|
||||
consistency group and restore all shares that were associated with a
|
||||
@ -32,7 +32,7 @@ Consistency groups
|
||||
Before using consistency groups, make sure the Shared File System driver
|
||||
that you are running has consistency group support. You can check it in the
|
||||
``manila-scheduler`` service reports. The ``consistency_group_support`` can
|
||||
have such values:
|
||||
have the following values:
|
||||
|
||||
* ``pool`` or ``host``. Consistency groups are supported. Specifies the
|
||||
level of consistency groups support.
|
||||
@ -64,7 +64,7 @@ specifying two comma-separated share types:
|
||||
| name | cgroup1 |
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
Check that consistency group is in available status:
|
||||
Check that consistency group status is ``available``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -86,13 +86,14 @@ Check that consistency group is in available status:
|
||||
| name | cgroup1 |
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
To add a share to the consistency group create a share with a
|
||||
To add a share to the consistency group, create a share by adding the
|
||||
:option:`--consistency-group` option where you specify the ID of the consistency
|
||||
group in ``available`` status:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ manila create nfs 1 --name "Share2" --description "My second share" --share-type default --share-network my_share_net --consistency-group cgroup1
|
||||
$ manila create nfs 1 --name "Share2" --description "My second share"
|
||||
--share-type default --share-network my_share_net --consistency-group cgroup1
|
||||
+-----------------------------+--------------------------------------+
|
||||
| Property | Value |
|
||||
+-----------------------------+--------------------------------------+
|
||||
@ -122,11 +123,11 @@ group in ``available`` status:
|
||||
+-----------------------------+--------------------------------------+
|
||||
|
||||
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.
|
||||
description using the :command:`manila cg-update` command. Delete the group
|
||||
with the :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
|
||||
force delete a specified consistency group in any state. Use the
|
||||
``policy.json`` file to grant permissions for these actions to other roles.
|
||||
|
||||
Use :command:`manila cg-reset-state [--state <state>] <consistency_group>`
|
||||
@ -163,10 +164,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,
|
||||
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.
|
||||
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 new consistency group.
|
||||
|
||||
Create a snapshot of consistency group ``cgroup1``:
|
||||
|
||||
@ -202,7 +202,7 @@ Check the status of created consistency group snapshot:
|
||||
| description | A snapshot of the first CG. |
|
||||
+----------------------+--------------------------------------+
|
||||
|
||||
Administrators can rename the consistency group snapshot, or change its
|
||||
Administrators can rename a consistency group snapshot, change its
|
||||
description using the :command:`cg-snapshot-update` command, or delete
|
||||
it with the :command:`cg-snapshot-delete` command.
|
||||
|
||||
@ -210,7 +210,7 @@ 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
|
||||
and operating with consistency group snapshots, you can quickly
|
||||
find which shares belong to a specified consistency group.
|
||||
|
||||
You created the share ``Share2`` in ``cgroup1`` consistency group. Since
|
||||
@ -227,7 +227,7 @@ group snapshot is ``Share2`` share:
|
||||
+--------------+------+----------------------------+----------------+--------------+--------------+
|
||||
|
||||
After you create a consistency group snapshot, you can create a consistency
|
||||
group from it:
|
||||
group from the new snapshot:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -316,7 +316,7 @@ Print detailed information about new share:
|
||||
+-----------------------------+---------------------------------------------------------------+
|
||||
|
||||
As an administrator, you can also reset the state of a consistency group
|
||||
snapshot with :command:`cg-snapshot-reset-state` and force-delete a specified
|
||||
consistency group snapshot in any state using :command:`cg-snapshot-delete`
|
||||
with :option:`--force` key. Use the ``policy.json`` file to grant permissions for
|
||||
snapshot with the :command:`cg-snapshot-reset-state` command, and force delete a specified
|
||||
consistency group snapshot in any state using the :command:`cg-snapshot-delete` command
|
||||
with the :option:`--force` key. Use the ``policy.json`` file to grant permissions for
|
||||
these actions to other roles.
|
||||
|
||||
@ -7,7 +7,8 @@ Share basic operations
|
||||
General concepts
|
||||
----------------
|
||||
|
||||
As general concepts, to create a file share and access it you need to:
|
||||
To create a file share, and access it, the following general concepts
|
||||
are prerequisite knowledge:
|
||||
|
||||
#. To create a share, use :command:`manila create` command and
|
||||
specify the required arguments: the size of the share and the shared file
|
||||
|
||||
@ -9,7 +9,7 @@ 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. Compute instances access these
|
||||
persistent, readable, and writable filesystems. Compute instances access these
|
||||
filesystems. Depending on the deployment configuration, clients outside of
|
||||
OpenStack can also access the filesystem.
|
||||
|
||||
@ -25,15 +25,16 @@ 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.
|
||||
can serve as the content source for a new ``share``. Specify the
|
||||
**Create from snapshot** option when creating a new ``share`` on the
|
||||
dashboard.
|
||||
|
||||
Storage Pools
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
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
|
||||
resource pools that the Shared File Systems service
|
||||
will select as a storage location when provisioning ``shares``.
|
||||
|
||||
Share Type
|
||||
@ -58,19 +59,19 @@ IP networks in CIDR notation.
|
||||
Security Services
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
``Security services``allow granular client access rules for cloud
|
||||
``Security services``allow granular client access rules for
|
||||
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. 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.
|
||||
Active Directory, and 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
|
||||
tenant network and subnet, as defined in an OpenStack Networking service or
|
||||
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
|
||||
|
||||
@ -4,29 +4,32 @@
|
||||
Manage and unmanage share
|
||||
=========================
|
||||
|
||||
To ``manage`` a share means that an administrator rather than a share driver
|
||||
manages the storage lifecycle. This approach is appropriate when an
|
||||
To ``manage`` a share means that an administrator, rather than a share
|
||||
driver, manages the storage lifecycle. This approach is appropriate when an
|
||||
administrator already has the custom non-manila share with its size, shared
|
||||
file system protocol, export path and so on, and administrator wants to
|
||||
file system protocol, and export path, and an administrator wants to
|
||||
register it in the Shared File System service.
|
||||
|
||||
To ``unmanage`` a share means to unregister a specified share from the Shared
|
||||
File Systems service. An administrator can manage the custom share back.
|
||||
File Systems service. Administrators can revert an unmanaged share to managed
|
||||
status if needed.
|
||||
|
||||
.. _unmanage_share:
|
||||
|
||||
Unmanage share
|
||||
--------------
|
||||
You can ``unmanage`` a share, to unregister it from the Shared File System
|
||||
service, and take manual control on share lifecycle. The ``unmanage``
|
||||
operation is not supported for shares that were created on top of share servers
|
||||
and created with share networks), so share service should have option
|
||||
``driver_handles_share_servers = False`` in its configuration. You can unmanage
|
||||
a share that has no dependent snapshots.
|
||||
Unmanage a share
|
||||
----------------
|
||||
|
||||
To unmanage managed share, run :command:`manila unmanage <share>` command.
|
||||
Then try to print the information about it. The expected behavior is that
|
||||
Shared File Systems service won't find the share:
|
||||
The ``unmanage`` operation is not supported for shares that were
|
||||
created on top of share servers and created with share networks.
|
||||
The Share service should have the
|
||||
option ``driver_handles_share_servers = False``
|
||||
set in the ``manila.conf`` file. You can unmanage a share that has
|
||||
no dependent snapshots.
|
||||
|
||||
To unmanage managed share, run the :command:`manila unmanage <share>`
|
||||
command. Then try to print the information about the share. The
|
||||
returned result should indicate that Shared File Systems service won't
|
||||
find the share:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -36,10 +39,10 @@ Shared File Systems service won't find the share:
|
||||
|
||||
.. _manage_share:
|
||||
|
||||
Manage share
|
||||
------------
|
||||
To register the non-managed share in File System service you need to run
|
||||
:command:`manila manage` command which has such arguments:
|
||||
Manage a share
|
||||
--------------
|
||||
To register the non-managed share in the File System service, run the
|
||||
:command:`manila manage` command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -50,12 +53,13 @@ To register the non-managed share in File System service you need to run
|
||||
|
||||
The positional arguments are:
|
||||
|
||||
- service_host. The manage-share service host in this format:
|
||||
``host@backend#POOL`` which consists of the host name for the back end,
|
||||
the name of the back end and the pool name for the back end.
|
||||
- service_host. The manage-share service host in
|
||||
``host@backend#POOL`` format, which consists of the host name for
|
||||
the back end, the name of the back end, and the pool name for the
|
||||
back end.
|
||||
|
||||
- protocol. The Shared File Systems protocol of the share to manage. A valid
|
||||
value is NFS, CIFS, GlusterFS, or HDFS.
|
||||
- protocol. The Shared File Systems protocol of the share to manage. Valid
|
||||
values are NFS, CIFS, GlusterFS, or HDFS.
|
||||
|
||||
- export_path. The share export path in the format appropriate for the
|
||||
protocol:
|
||||
@ -68,10 +72,10 @@ The positional arguments are:
|
||||
|
||||
- GlusterFS. 10.0.0.1:/foo_volume.
|
||||
|
||||
The ``driver_options`` is an optional set of one or more key and value pairs,
|
||||
that describe driver options. Note that the share type must have
|
||||
``driver_handles_share_servers = False`` option, so special share type named
|
||||
``for_managing`` was used in example.
|
||||
The ``driver_options`` is an optional set of one or more key and value pairs
|
||||
that describe driver options. Note that the share type must have the
|
||||
``driver_handles_share_servers = False`` option. As a result, a special share
|
||||
type named ``for_managing`` was used in example.
|
||||
|
||||
To manage share, run:
|
||||
|
||||
|
||||
@ -5,12 +5,11 @@ Networking
|
||||
==========
|
||||
|
||||
Unlike the OpenStack Block Storage service, the Shared File Systems service
|
||||
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
|
||||
authentication services, like LDAP, Kerberos protocols, or Microsoft Active
|
||||
Directory.
|
||||
must connect to the Networking service. The share service requires the
|
||||
option to self-manage share servers. For client authentication and
|
||||
authorization, you can configure the Shared File Systems service to
|
||||
work with different network authentication services, like LDAP, Kerberos
|
||||
protocols, or Microsoft Active Directory.
|
||||
|
||||
.. toctree::
|
||||
|
||||
|
||||
@ -35,11 +35,11 @@ To see the absolute limits, run:
|
||||
Rate limits control the frequency at which users can issue specific API
|
||||
requests. Administrators use rate limiting to configure limits on the type and
|
||||
number of API calls that can be made in a specific time interval. For example,
|
||||
a rate limit can control the number of GET requests that can be processed
|
||||
a rate limit can control the number of ``GET`` requests processed
|
||||
during a one-minute period.
|
||||
|
||||
To set the API rate limits, add configuration to the
|
||||
``etc/manila/api-paste.ini`` file that is a part of the WSGI pipeline and
|
||||
To set the API rate limits, modify the
|
||||
``etc/manila/api-paste.ini`` file, which is a part of the WSGI pipeline and
|
||||
defines the actual limits. You need to restart ``manila-api`` service after
|
||||
you edit the ``etc/manila/api-paste.ini`` file.
|
||||
|
||||
@ -49,7 +49,7 @@ you edit the ``etc/manila/api-paste.ini`` file.
|
||||
paste.filter_factory = manila.api.v1.limits:RateLimitingMiddleware.factory
|
||||
limits = (POST, "*/shares", ^/shares, 120, MINUTE);(PUT, "*/shares", .*, 120, MINUTE);(DELETE, "*", .*, 120, MINUTE)
|
||||
|
||||
Also, add ``ratelimit`` to ``noauth``, ``keystone``, ``keystone_nolimit``
|
||||
Also, add the ``ratelimit`` to ``noauth``, ``keystone``, ``keystone_nolimit``
|
||||
parameters in the ``[composite:openstack_share_api]`` group.
|
||||
|
||||
.. code-block:: ini
|
||||
@ -75,7 +75,7 @@ To see the rate limits, run:
|
||||
Quotas
|
||||
~~~~~~
|
||||
|
||||
Quota sets provide quotas management support.
|
||||
Quota sets provide quota management support.
|
||||
|
||||
To list the quotas for a tenant or user, use the :command:`manila quota-show`
|
||||
command. If you specify the optional :option:`--user` parameter, you get the
|
||||
@ -112,8 +112,8 @@ the :command:`manila quota-defaults` command:
|
||||
| share_networks | 10 |
|
||||
+--------------------+-------+
|
||||
|
||||
The administrator can update the quotas for a specified tenant or for a
|
||||
specified user by providing both the ``--tenant`` and ``--user`` optional
|
||||
The administrator can update the quotas for a specific tenant, or for a
|
||||
specific user by providing both the ``--tenant`` and ``--user`` optional
|
||||
arguments. It is possible to update the ``snapshots``, ``gigabytes``,
|
||||
``snapshot-gigabytes``, and ``share-networks`` quotas.
|
||||
|
||||
@ -122,8 +122,8 @@ arguments. It is possible to update the ``snapshots``, ``gigabytes``,
|
||||
$ manila quota-update demo --user demo --shares 49 --snapshots 49
|
||||
|
||||
As administrator, you can also permit or deny the force-update of a quota that
|
||||
is already used and the requested value exceeds the configured quota. To
|
||||
force-update a quota, use ``force`` optional key.
|
||||
is already used, or if the requested value exceeds the configured quota limit.
|
||||
To force-update a quota, use ``force`` optional key.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
@ -4,29 +4,30 @@
|
||||
Scheduling
|
||||
==========
|
||||
|
||||
The Shared File Systems service provides unified access for a variety of
|
||||
different types of shared file systems. To achieve this, the Shared File
|
||||
Systems service uses a scheduler. The scheduler collects information from
|
||||
the active shared services and makes decisions such as what shared services
|
||||
will be used to create a new share. To manage this process, the Shared
|
||||
File Systems service provides Share types API.
|
||||
The Shared File Systems service uses a scheduler to provide unified
|
||||
access for a variety of different types of shared file systems. The
|
||||
scheduler collects information from the active shared services, and
|
||||
makes decisions such as what shared services will be used to create
|
||||
a new share. To manage this process, the Shared File Systems service
|
||||
provides Share types API.
|
||||
|
||||
A share type is a list from key-value pairs called extra-specs. Some of them,
|
||||
called required and un-scoped extra-specs, the scheduler uses for lookup of
|
||||
the shared service suitable for a new share with the specified share type.
|
||||
A share type is a list from key-value pairs called extra-specs. The
|
||||
scheduler uses required and un-scoped extra-specs to look up
|
||||
the shared service most suitable for a new share with the specified share type.
|
||||
For more information about extra-specs and their type, see `Capabilities
|
||||
and Extra-Specs <http://docs.openstack.org/developer/manila/devref/capabilities_and_extra_specs.html>`_ section in developer documentation.
|
||||
|
||||
The general scheduler workflow is described below.
|
||||
The general scheduler workflow:
|
||||
|
||||
#. Share services report information about the number of existing pools, their
|
||||
capacities and capabilities.
|
||||
#. Share services report information about their existing pool number, their
|
||||
capacities, and their capabilities.
|
||||
|
||||
#. When a request on share creation comes in, the scheduler picks a service
|
||||
and pool that fits the need best to serve the request, using share type
|
||||
#. When a request on share creation arrives, the scheduler picks a service
|
||||
and pool that best serves the request, using share type
|
||||
filters and back end capabilities. If back end capabilities pass through,
|
||||
all filters request to the selected back end where the target pool resides.
|
||||
all filters request the selected back end where the target pool resides.
|
||||
|
||||
#. The share driver gets the message and lets the target pool serve the
|
||||
request as the scheduler instructs. The scoped and un-scoped share type
|
||||
extra-specs are available for the driver implementation to use as needed.
|
||||
#. The share driver receives a reply on the request status, and lets the
|
||||
target pool serve the request as the scheduler instructs. The scoped
|
||||
and un-scoped share types are available for the driver implementation
|
||||
to use as needed.
|
||||
|
||||
@ -7,12 +7,12 @@ Share networks
|
||||
Share network is an entity that encapsulates interaction with the OpenStack
|
||||
Networking service. If the share driver that you selected runs in a mode
|
||||
requiring Networking service interaction, specify the share network when
|
||||
creating a share network.
|
||||
creating a new share network.
|
||||
|
||||
How to create share network
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
List networks in a tenant, run:
|
||||
To list networks in a tenant, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -60,7 +60,8 @@ To create a share network with private network and subnetwork, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ manila share-network-create --neutron-net-id 5ed5a854-21dc-4ed3-870a-117b7064eb21 --neutron-subnet-id 74dcfb5a-b4d7-4855-86f5-a669729428dc --name my_share_net --description "My first share network"
|
||||
$ manila share-network-create --neutron-net-id 5ed5a854-21dc-4ed3-870a-117b7064eb21
|
||||
--neutron-subnet-id 74dcfb5a-b4d7-4855-86f5-a669729428dc --name my_share_net --description "My first share network"
|
||||
+-------------------+--------------------------------------+
|
||||
| Property | Value |
|
||||
+-------------------+--------------------------------------+
|
||||
@ -83,7 +84,7 @@ The ``segmentation_id``, ``cidr``, ``ip_version``, and ``network_type``
|
||||
share network attributes are automatically set to the values determined by the
|
||||
network provider.
|
||||
|
||||
Check network list, run:
|
||||
To check the network list, run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -94,10 +95,11 @@ Check network list, run:
|
||||
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a | my_share_net |
|
||||
+--------------------------------------+--------------+
|
||||
|
||||
If you configured the Generic driver with ``driver_handles_share_servers =
|
||||
True`` (with the share servers) and had already some operations in the Shared
|
||||
If you configured the generic driver with ``driver_handles_share_servers =
|
||||
True`` (with the share servers) and already had previous operations in the Shared
|
||||
File Systems service, you can see ``manila_service_network`` in the neutron
|
||||
list of networks. This network was created by Generic driver for inner usage.
|
||||
list of networks. This network was created by the generic driver for internal
|
||||
use.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -113,7 +115,7 @@ list of networks. This network was created by Generic driver for inner usage.
|
||||
+--------------+------------------------+------------------------------------+
|
||||
|
||||
You also can see detailed information about the share network including
|
||||
``network_type``, ``segmentation_id`` fields:
|
||||
``network_type``, and ``segmentation_id`` fields:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -136,5 +138,5 @@ You also can see detailed information about the share network including
|
||||
| tenant_id | 24c6491074e942309a908c674606f598 |
|
||||
+---------------------------+--------------------------------------+
|
||||
|
||||
You also can add and remove the security services to the share network. For
|
||||
details, see :ref:`shared_file_systems_security_services`.
|
||||
You also can add and remove the security services from the share network.
|
||||
For more detail, see :ref:`shared_file_systems_security_services`.
|
||||
|
||||
@ -4,19 +4,19 @@
|
||||
Resize share
|
||||
============
|
||||
|
||||
To change file share size, use :command:`manila extend` and
|
||||
:command:`manila shrink`. For most drivers it is safe operation. If you want to
|
||||
be sure that your data is safe, you can make a share back up by creating a
|
||||
snapshot of it.
|
||||
To change file share size, use the :command:`manila extend` command and
|
||||
the :command:`manila shrink` command. For most drivers it is safe
|
||||
operation. If you want to be sure that your data is safe, you can make
|
||||
a share back up by creating a snapshot of it.
|
||||
|
||||
You can extend and shrink the share with the :command:`manila extend` and
|
||||
:command:`manila shrink` commands respectively and specifying the share
|
||||
:command:`manila shrink` commands respectively, and specify the share
|
||||
with the new size that does not exceed the quota. For details, see
|
||||
:ref:`Quotas and Limits <shared_file_systems_quotas>`. You also cannot shrink
|
||||
size to 0 or to a greater value than the current share size.
|
||||
share size to 0 or to a greater value than the current share size.
|
||||
|
||||
While extending the share gets ``extending`` status that means that the
|
||||
increase share size request was issued successfully.
|
||||
While extending, the share has an ``extending`` status. This means that
|
||||
the increase share size request was issued successfully.
|
||||
|
||||
To extend the share and check the result, run:
|
||||
|
||||
@ -51,7 +51,7 @@ To extend the share and check the result, run:
|
||||
| metadata | {u'deadline': u'01/30/16'} |
|
||||
+-----------------------------+-------------------------------------------+
|
||||
|
||||
While shrinking the share gets ``shrinking`` status that means that the
|
||||
While shrinking, the share has a ``shrinking`` status. This means that the
|
||||
decrease share size request was issued successfully. To shrink the share and
|
||||
check the result, run:
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user