openstack-manuals/doc/admin-guide-cloud/source/shared_file_systems_scheduling.rst
Joseph Robinson ae1ac53d49 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
2016-03-18 11:30:46 +10:00

1.5 KiB

Scheduling

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. 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 section in developer documentation.

The general scheduler workflow:

  1. Share services report information about their existing pool number, their capacities, and their capabilities.
  2. 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 the selected back end where the target pool resides.
  3. 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.