cinder.interface.volume_manageable_driver module
Manage/unmanage existing volume driver interface.
-
class
VolumeListManageableDriver
Bases: cinder.interface.volume_manageable_driver.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: cinder.interface.base.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:
- 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.
- 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: |
|
-
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 |