52370e58fe
These are in the cinder doc tree so of course they're block storage-related. Change-Id: Ic1950ff89021a89de397619eef17f8100eb3d847 Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
72 lines
2.7 KiB
ReStructuredText
72 lines
2.7 KiB
ReStructuredText
====================
|
||
Default Volume Types
|
||
====================
|
||
|
||
Beginning with the Train release, untyped volumes (that is, volumes with no
|
||
volume-type) have been disallowed. To facilitate this, a ``__DEFAULT__``
|
||
volume-type was included as part of the Train database migration.
|
||
Since the Train release, handling of the default volume-type has been
|
||
improved:
|
||
|
||
- The default_volume_type configuration option is required to have a value.
|
||
The default value is ``__DEFAULT__``.
|
||
|
||
- A request to delete the currently configured default_volume_type will fail.
|
||
(You can delete that volume-type, but you cannot do it while it is the value
|
||
of the configuration option.)
|
||
|
||
- There must always be at least one volume-type defined in a Cinder
|
||
installation. This is enforced by the type-delete call.
|
||
|
||
- If the default_volume_type is misconfigured (that is, if the value refers to
|
||
a non-existent volume-type), requests that rely on the default volume-type
|
||
(for example, a volume-create request that does not specify a volume-type)
|
||
will result in a HTTP 500 response.
|
||
|
||
Default types per project
|
||
-------------------------
|
||
|
||
We have overriden the existing Cinder default Volume Type on a per project
|
||
basis to make it easier to manage complex deployments.
|
||
|
||
With the introduction of this new default volume type support, we’ll now
|
||
have 2 different default volume types. From more specific to more generic these
|
||
are:
|
||
|
||
- Per project
|
||
|
||
- Defined in cinder.conf (defaults to ``__DEFAULT__`` type)
|
||
|
||
So when a user creates a new volume that has no defined volume type
|
||
(explicit or in the source), Cinder will look for the appropriate default
|
||
first by checking if there’s one defined in the DB for the specific project
|
||
and use it, if there isn’t one, it will continue like it does today,
|
||
using the default type from cinder.conf.
|
||
|
||
Administrators and users must still be careful with the normal Cinder behavior
|
||
when creating volumes, as Cinder will still only resort to using the default
|
||
volume type if the user doesn’t select one on the request or if there’s no
|
||
volume type in the source, which means that Cinder will not use any of those
|
||
defaults if we:
|
||
|
||
- Create a volume providing a volume type
|
||
|
||
- Create a volume from a snapshot
|
||
|
||
- Clone a volume
|
||
|
||
- Create a volume from an image that has cinder_img_volume_type defined in its
|
||
metadata.
|
||
|
||
There is a new set of commands in the python-cinderclient to match the new
|
||
REST API endpoints:
|
||
|
||
- Set default: ``cinder default-type-set <project-id> <type-name>``
|
||
|
||
- Unset default: ``cinder default-type-unset <project-id>``
|
||
|
||
- List defaults: ``cinder default-type-list [--project <project-id>]``
|
||
|
||
By default the policy restricting access to set, unset, get or list all
|
||
project default volume type is set to admins only.
|