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.