=====================================
Cinder Block Storage service overview
=====================================

The OpenStack Block Storage service (Cinder) adds persistent storage
to a virtual machine. Block Storage provides an infrastructure for managing
volumes, and interacts with OpenStack Compute to provide volumes for
instances. The service also enables management of volume snapshots, and
volume types.

The Block Storage service consists of the following components:

cinder-api
  Accepts API requests, and routes them to the ``cinder-volume`` for
  action.

cinder-volume
  Interacts directly with the Block Storage service, and processes
  such as the ``cinder-scheduler``. It also interacts with these processes
  through a message queue. The ``cinder-volume`` service responds to read
  and write requests sent to the Block Storage service to maintain
  state. It can interact with a variety of storage providers through a
  driver architecture.

cinder-scheduler daemon
  Selects the optimal storage provider node on which to create the
  volume. A similar component to the ``nova-scheduler``.

cinder-backup daemon
  The ``cinder-backup`` service provides backing up volumes of any type to
  a backup storage provider. Like the ``cinder-volume`` service, it can
  interact with a variety of storage providers through a driver
  architecture.

Messaging queue
  Routes information between the Block Storage processes.

The default volume type
-----------------------

Since the Train release, it is required that each volume must have a
*volume type*, and thus the required configuration option
``default_volume_type`` must have a value.  A system-defined volume type
named ``__DEFAULT__`` is created in the database during installation and
is the default value of the ``default_volume_type`` configuration option.

You (or your deployment tool) may wish to have a different volume type that
is more suitable for your particular installation as the default type.
This can be accomplished by creating the volume type you want using the
Block Storage API, and then setting that volume type as the value for
the configuration option.  (The latter operation, of course, cannot be
done via the Block Storage API.)

The system defined ``__DEFAULT__`` volume type is a regular volume type
that may be updated or deleted.  There is nothing special about it.  It only
exists because there must always be at least one volume type in a cinder
deployment, and before the Block Storage API comes up, there is no way for
there to be a volume type unless the system creates it.

Given that since the Victoria release it is possible to set a default
volume type for any project, having a volume type named ``__DEFAULT__``
in your deployment may be confusing to your users, leading them to think this
is the type that will be assigned while creating volumes (if the user doesn't
specify one) or them specifically requesting ``__DEFAULT__`` when creating a
volume instead of the actual configured default type for the system or their
project.

If you don't wish to use the ``__DEFAULT__`` type, you may delete it.  The
Block Storage API will prevent deletion under these circumstances:

* If ``__DEFAULT__`` is the value of the ``default_volume_type`` configuration
  option then it cannot be deleted.  The solution is to make a different
  volume type the value of that configuration option.
* If there are volumes in the deployment of the ``__DEFAULT__`` type, then
  it cannot be deleted.  The solution is to retype those volumes to some
  other appropriate volume type.