openstack/openstack-manuals
Code Issues Proposed changes

cleanup of shared file systems scheduling file

Browse Source 
changed sentences
added the and a where necessary
reworded sentences

Change-Id: I2b5f913b223f63b12d5d14656a7aa966ac7fd7c7
This commit is contained in:
Shilla Saebi 2015-11-12 00:19:43 -05:00
parent 3bc2c009ec
commit 771e527fa2
1 changed files with 17 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
doc/admin-guide-cloud/source/shared_file_systems_scheduling.rst
View File

@ -4,30 +4,29 @@
Scheduling
==========
The Shared File Systems service provides unified access for variety of
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
active share services and takes decisions, what share service will be used to
create a new share. To manage this process, the Shared File Systems service
provides Share types API.
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, scheduler uses for lookup the
share service suitable for new share with 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_spec
s.html>`_ section in developer documentation.
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.
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 in described below.
The general scheduler workflow is described below.
#. Share services report information about number of existing pools, their
#. Share services report information about the number of existing pools, their
capacities and capabilities.
#. When request on share creation comes in, scheduler picks a service and pool
that fits the need best to serve the request, using share type filters and
back end capabilities. If back end capabilities passes thought all filters
request to the selected back end where the target pool resides.
#. 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
filters and back end capabilities. If back end capabilities pass through,
all filters request to the selected back end where the target pool resides.
#. Share driver gets the message and lets the target pool serve the request
as scheduler instructed. The scoped and un-scoped share type extra-specs
are available for the driver implementation to use as needed.
#. 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.