cinder.interface.volume_manageable_driver module¶

Manage/unmanage existing volume driver interface.

class VolumeListManageableDriver¶

Bases: VolumeManagementDriver

Interface to support listing manageable snapshots and volumes.

get_manageable_snapshots(cinder_snapshots, marker, limit, offset, sort_keys, sort_dirs)¶

List snapshots on the backend available for management by Cinder.

Returns a list of dictionaries, each specifying a snapshot in the host, with the following keys:

• reference (dictionary): The reference for a snapshot, which can be passed to “manage_existing_snapshot”.

• size (int): The size of the snapshot according to the storage backend, rounded up to the nearest GB.

• safe_to_manage (boolean): Whether or not this snapshot is safe to manage according to the storage backend. For example, is the snapshot in use or invalid for any reason.

• reason_not_safe (string): If safe_to_manage is False, the reason why.

• cinder_id (string): If already managed, provide the Cinder ID.

• extra_info (string): Any extra information to return to the user

• source_reference (string): Similar to “reference”, but for the snapshot’s source volume.

Parameters:

• cinder_snapshots – A list of snapshots in this host that Cinder currently manages, used to determine if a snapshot is manageable or not.

• marker – The last item of the previous page; we return the next results after this value (after sorting)

• limit – Maximum number of items to return

• offset – Number of items to skip after marker

• sort_keys – List of keys to sort results by (valid keys are ‘identifier’ and ‘size’)

• sort_dirs – List of directions to sort by, corresponding to sort_keys (valid directions are ‘asc’ and ‘desc’)

get_manageable_volumes(cinder_volumes, marker, limit, offset, sort_keys, sort_dirs)¶

List volumes on the backend available for management by Cinder.

Returns a list of dictionaries, each specifying a volume in the host, with the following keys:

• reference (dictionary): The reference for a volume, which can be passed to “manage_existing”.

• size (int): The size of the volume according to the storage backend, rounded up to the nearest GB.

• safe_to_manage (boolean): Whether or not this volume is safe to manage according to the storage backend. For example, is the volume in use or invalid for any reason.

• reason_not_safe (string): If safe_to_manage is False, the reason why.

• cinder_id (string): If already managed, provide the Cinder ID.

• extra_info (string): Any extra information to return to the user

Parameters:

• cinder_volumes – A list of volumes in this host that Cinder currently manages, used to determine if a volume is manageable or not.

• marker – The last item of the previous page; we return the next results after this value (after sorting)

• limit – Maximum number of items to return

• offset – Number of items to skip after marker

• sort_keys – List of keys to sort results by (valid keys are ‘identifier’ and ‘size’)

• sort_dirs – List of directions to sort by, corresponding to sort_keys (valid directions are ‘asc’ and ‘desc’)

class VolumeManagementDriver¶

Bases: CinderInterface

Interface for drivers that support managing existing volumes.

manage_existing(volume, existing_ref)¶

Brings an existing backend storage object under Cinder management.

existing_ref is passed straight through from the API request’s manage_existing_ref value, and it is up to the driver how this should be interpreted. It should be sufficient to identify a storage object that the driver should somehow associate with the newly-created cinder volume structure.

There are two ways to do this:

1. Rename the backend storage object so that it matches the, volume[‘name’] which is how drivers traditionally map between a cinder volume and the associated backend storage object.

2. Place some metadata on the volume, or somewhere in the backend, that allows other driver requests (e.g. delete, clone, attach, detach…) to locate the backend storage object when required.

If the existing_ref doesn’t make sense, or doesn’t refer to an existing backend storage object, raise a ManageExistingInvalidReference exception.

The volume may have a volume_type, and the driver can inspect that and compare against the properties of the referenced backend storage object. If they are incompatible, raise a ManageExistingVolumeTypeMismatch, specifying a reason for the failure.

Parameters:

• volume – Cinder volume to manage

• existing_ref – Dictionary with keys ‘source-id’, ‘source-name’ with driver-specific values to identify a backend storage object.

Raises:

• ManageExistingInvalidReference – If the existing_ref doesn’t make sense, or doesn’t refer to an existing backend storage object.

• ManageExistingVolumeTypeMismatch – If there is a mismatch between the volume type and the properties of the existing backend storage object.

manage_existing_get_size(volume, existing_ref)¶

Return size of volume to be managed by manage_existing.

When calculating the size, round up to the next GB.

Parameters:

• volume – Cinder volume to manage

• existing_ref – Dictionary with keys ‘source-id’, ‘source-name’ with driver-specific values to identify a backend storage object.

Raises:

ManageExistingInvalidReference – If the existing_ref doesn’t make sense, or doesn’t refer to an existing backend storage object.

unmanage(volume)¶

Removes the specified volume from Cinder management.

Does not delete the underlying backend storage object.

For most drivers, this will not need to do anything. However, some drivers might use this call as an opportunity to clean up any Cinder-specific configuration that they have associated with the backend storage object.

Parameters:

volume – Cinder volume to unmanage