Drivers¶

Cinder exposes an API to users to interact with different storage backend solutions. The following are standards across all drivers for Cinder services to properly interact with a driver.

Basic attributes¶

There are some basic attributes that all drivers classes should have:

VERSION: Driver version in string format. No naming convention is imposed, although semantic versioning is recommended.
CI_WIKI_NAME: Must be the exact name of the ThirdPartySystems wiki page. This is used by our tooling system to associate jobs to drivers and track their CI reporting status correctly.

The tooling system will also use the name and docstring of the driver class.

Minimum Features¶

Minimum features are enforced to avoid having a grid of what features are supported by which drivers and which releases. Cinder Core requires that all drivers implement the following minimum features.

Core Functionality¶

Volume Create/Delete
Volume Attach/Detach
Snapshot Create/Delete
Create Volume from Snapshot
Get Volume Stats
Copy Image to Volume
Copy Volume to Image
Clone Volume
Extend Volume

Volume Stats¶

Volume stats are used by the different schedulers for the drivers to provide a report on their current state of the backend. The following should be provided by a driver.

driver_version
free_capacity_gb
storage_protocol
total_capacity_gb
vendor_name
volume_backend_name

NOTE: If the driver is unable to provide a value for free_capacity_gb or total_capacity_gb, keywords can be provided instead. Please use ‘unknown’ if the backend cannot report the value or ‘infinite’ if the backend has no upper limit. But, it is recommended to report real values as the Cinder scheduler assigns lowest weight to any storage backend reporting ‘unknown’ or ‘infinite’.

Feature Enforcement¶

All concrete driver implementations should use the cinder.interface.volumedriver decorator on the driver class:

@interface.volumedriver
class LVMVolumeDriver(driver.VolumeDriver):

This will register the driver and allow automated compliance tests to run against and verify the compliance of the driver against the required interface to support the Core Functionality listed above.

Running tox -e compliance will verify all registered drivers comply to this interface. This can be used during development to perform self checks along the way. Any missing method calls will be identified by the compliance tests.

The details for the required volume driver interfaces can be found in the cinder/interface/volume_*_driver.py source.

Driver Development Documentations¶

The LVM driver is our reference for all new driver implementations. The information below can provide additional documentation for the methods that volume drivers need to implement.

Base Driver Interface¶

The methods documented below are the minimum required interface for a volume driver to support. All methods from this interface must be implemented in order to be an official Cinder volume driver.

Core backend volume driver interface.

All backend drivers should support this interface as a bare minimum.

class VolumeDriverCore¶

Core backend driver required interface.

attach_volume(context, volume, instance_uuid, host_name, mountpoint)¶

Lets the driver know Nova has attached the volume to an instance.

Parameters:	context – Security/policy info for the request. volume – Volume being attached. instance_uuid – ID of the instance being attached to. host_name – The host name. mountpoint – Device mount point on the instance.

check_for_setup_error()¶

Validate there are no issues with the driver configuration.

Called after do_setup(). Driver initialization can occur there or in this call, but must be complete by the time this returns.

If this method raises an exception, the driver will be left in an “uninitialized” state by the volume manager, which means that it will not be sent requests for volume operations.

This method typically checks things like whether the configured credentials can be used to log in the storage backend, and whether any external dependencies are present and working.

Raises:	VolumeBackendAPIException in case of setup error.

clone_image(volume, image_location, image_id, image_metadata, image_service)¶

Clone an image to a volume.

Parameters:	volume – The volume to create. image_location – Where to pull the image from. image_id – The image identifier. image_metadata – Information about the image. image_service – The image service to use.
Returns:	Model updates.

copy_image_to_volume(context, volume, image_service, image_id)¶

Fetch the image from image_service and write it to the volume.

Parameters:	context – Security/policy info for the request. volume – The volume to create. image_service – The image service to use. image_id – The image identifier.
Returns:	Model updates.

copy_volume_to_image(context, volume, image_service, image_meta)¶

Copy the volume to the specified image.

Parameters:	context – Security/policy info for the request. volume – The volume to copy. image_service – The image service to use. image_meta – Information about the image.
Returns:	Model updates.

create_volume(volume)¶

Create a new volume on the backend.

This method is responsible only for storage allocation on the backend. It should not export a LUN or actually make this storage available for use, this is done in a later call.

# TODO(smcginnis) - Add example data structure of volume object. :param volume: Volume object containing specifics to create. :returns: (Optional) dict of database updates for the new volume. :raises: VolumeBackendAPIException if creation failed.

delete_volume(volume)¶

Delete a volume from the backend.

If the driver can talk to the backend and detects that the volume is no longer present, this call should succeed and allow Cinder to complete the process of deleting the volume.

Parameters:	volume – The volume to delete.
Raises:	VolumeIsBusy if the volume is still attached or has snapshots. VolumeBackendAPIException on error.

detach_volume(context, volume, attachment=None)¶

Detach volume from an instance.

Parameters:	context – Security/policy info for the request. volume – Volume being detached. attachment – (Optional) Attachment information.

do_setup(context)¶

Any initialization the volume driver needs to do while starting.

Called once by the manager after the driver is loaded. Can be used to set up clients, check licenses, set up protocol specific helpers, etc.

Parameters:	context – The admin context.

extend_volume(volume, new_size)¶

Extend the size of a volume.

Parameters:	volume – The volume to extend. new_size – The new desired size of the volume.

get_volume_stats(refresh=False)¶

Collects volume backend stats.

The get_volume_stats method is used by the volume manager to collect information from the driver instance related to information about the driver, available and used space, and driver/backend capabilities.

It returns a dict with the following required fields:

volume_backend_name

This is an identifier for the backend taken from cinder.conf. Useful when using multi-backend.
vendor_name

Vendor/author of the driver who serves as the contact for the driver’s development and support.
driver_version

The driver version is logged at cinder-volume startup and is useful for tying volume service logs to a specific release of the code. There are currently no rules for how or when this is updated, but it tends to follow typical major.minor.revision ideas.
storage_protocol

The protocol used to connect to the storage, this should be a short string such as: “iSCSI”, “FC”, “nfs”, “ceph”, etc.
total_capacity_gb

The total capacity in gigabytes (GiB) of the storage backend being used to store Cinder volumes. Use keyword ‘unknown’ if the backend cannot report the value or ‘infinite’ if there is no upper limit. But, it is recommended to report real values as the Cinder scheduler assigns lowest weight to any storage backend reporting ‘unknown’ or ‘infinite’.
free_capacity_gb

The free capacity in gigabytes (GiB). Use keyword ‘unknown’ if the backend cannot report the value or ‘infinite’ if there is no upper limit. But, it is recommended to report real values as the Cinder scheduler assigns lowest weight to any storage backend reporting ‘unknown’ or ‘infinite’.

And the following optional fields:

reserved_percentage (integer)

Percentage of backend capacity which is not used by the scheduler.
location_info (string)

Driver-specific information used by the driver and storage backend to correlate Cinder volumes and backend LUNs/files.
QoS_support (Boolean)

Whether the backend supports quality of service.
provisioned_capacity_gb

The total provisioned capacity on the storage backend, in gigabytes (GiB), including space consumed by any user other than Cinder itself.
max_over_subscription_ratio

The maximum amount a backend can be over subscribed.
thin_provisioning_support (Boolean)

Whether the backend is capable of allocating thinly provisioned volumes.
thick_provisioning_support (Boolean)

Whether the backend is capable of allocating thick provisioned volumes. (Typically True.)
total_volumes (integer)

Total number of volumes on the storage backend. This can be used in custom driver filter functions.
filter_function (string)

A custom function used by the scheduler to determine whether a volume should be allocated to this backend or not. Example:

capabilities.total_volumes < 10
goodness_function (string)

Similar to filter_function, but used to weigh multiple volume backends. Example:

capabilities.capacity_utilization < 0.6 ? 100 : 25
multiattach (Boolean)

Whether the backend supports multiattach or not. Defaults to False.
sparse_copy_volume (Boolean)

Whether copies performed by the volume manager for operations such as migration should attempt to preserve sparseness.

The returned dict may also contain a list, “pools”, which has a similar dict for each pool being used with the backend.

Parameters:	refresh – Whether to discard any cached values and force a full refresh of stats.
Returns:	dict of appropriate values (see above).

initialize_connection(volume, connector, initiator_data=None)¶

Allow connection to connector and return connection info.

Parameters:	volume – The volume to be attached. connector – Dictionary containing information about what is being connected to. initiator_data – (Optional) A dictionary of driver_initiator_data objects with key-value pairs that have been saved for this initiator by a driver in previous initialize_connection calls.
Returns:	A dictionary of connection information. This can optionally include a “initiator_updates” field.

The “initiator_updates” field must be a dictionary containing a “set_values” and/or “remove_values” field. The “set_values” field must be a dictionary of key-value pairs to be set/updated in the db. The “remove_values” field must be a list of keys, previously set with “set_values”, that will be deleted from the db.

May be called multiple times to get connection information after a volume has already been attached.

terminate_connection(volume, connector)¶

Remove access to a volume.

Parameters:	volume – The volume to remove. connector – The Dictionary containing information about the connection.

Snapshot Interface¶

Another required interface for a volume driver to be fully compatible is the ability to create and manage snapshots. Due to legacy constraints, this interface is not included in the base driver interface above.

Work is being done to address those legacy issues. Once that is complete, this interface will be merged with the base driver interface.

Snapshot capable volume driver interface.

class VolumeSnapshotDriver¶

Interface for drivers that support snapshots.

TODO(smcginnis) Merge into VolumeDriverBase once NFS driver supports snapshots.

create_snapshot(snapshot)¶

Creates a snapshot.

Parameters:	snapshot – Information for the snapshot to be created.

create_volume_from_snapshot(volume, snapshot)¶

Creates a volume from a snapshot.

If volume_type extra specs includes ‘replication: <is> True’ the driver needs to create a volume replica (secondary), and setup replication between the newly created volume and the secondary volume.

An optional larger size for the new snapshot can be specified. Drivers should check this value and create or expand the new volume to match.

Parameters:	volume – The volume to be created. snapshot – The snapshot from which to create the volume.
Returns:	A dict of database updates for the new volume.

delete_snapshot(snapshot)¶

Deletes a snapshot.

Parameters:	snapshot – The snapshot to delete.

Manage/Unmanage Support¶

An optional feature a volume backend can support is the ability to manage existing volumes or unmanage volumes - keep the volume on the storage backend but no longer manage it through Cinder.

To support this functionality, volume drivers must implement these methods:

Manage/unmanage existing volume driver interface.

class VolumeManagementDriver¶

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:	ManageExistingInvalidReference If the existing_ref doesn’t make sense, or doesn’t refer to an existing backend storage object.
Raises:	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

Manage/Unmanage Snapshot Support¶

In addition to the ability to manage and unmanage volumes, Cinder backend drivers may also support managing and unmanaging volume snapshots. These additional methods must be implemented to support these operations.

Manage/unmanage existing volume snapshots driver interface.

class VolumeSnapshotManagementDriver¶

Interface for drivers that support managing existing snapshots.

manage_existing_snapshot(snapshot, 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 snapshot structure.

There are two ways to do this:

Rename the backend storage object so that it matches the snapshot[‘name’] which is how drivers traditionally map between a cinder snapshot and the associated backend storage object.
Place some metadata on the snapshot, or somewhere in the backend, that allows other driver requests (e.g. delete) to locate the backend storage object when required.

Parameters:	snapshot – The snapshot 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.

manage_existing_snapshot_get_size(snapshot, existing_ref)¶

Return size of snapshot to be managed by manage_existing.

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

Parameters:	snapshot – The snapshot 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_snapshot(snapshot)¶

Removes the specified snapshot 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:	snapshot – The snapshot to unmanage.

Volume Consistency Groups¶

Some storage backends support the ability to group volumes and create write consistent snapshots across the group. In order to support these operations, the following interface must be implemented by the driver.

Consistency group volume driver interface.

class VolumeConsistencyGroupDriver¶

Interface for drivers that support consistency groups.

create_cgsnapshot(context, cgsnapshot, snapshots)¶

Creates a cgsnapshot.

Parameters:	context – the context of the caller. cgsnapshot – the dictionary of the cgsnapshot to be created. snapshots – a list of snapshot dictionaries in the cgsnapshot.
Returns:	model_update, snapshots_model_update

param snapshots is retrieved directly from the db. It is a list of cinder.db.sqlalchemy.models.Snapshot to be precise. It cannot be assigned to snapshots_model_update. snapshots_model_update is a list of dictionaries. It has to be built by the driver. An entry will be in this format: {‘id’: xxx, ‘status’: xxx, ......}. model_update will be in this format: {‘status’: xxx, ......}.

The driver should populate snapshots_model_update and model_update and return them.

The manager will check snapshots_model_update and update db accordingly for each snapshot. If the driver successfully deleted some snapshots but failed to delete others, it should set statuses of the snapshots accordingly so that the manager can update db correctly.

If the status in any entry of snapshots_model_update is ‘error’, the status in model_update will be set to the same if it is not already ‘error’.

If the status in model_update is ‘error’, the manager will raise an exception and the status of cgsnapshot will be set to ‘error’ in the db. If snapshots_model_update is not returned by the driver, the manager will set the status of every snapshot to ‘error’ in the except block.

If the driver raises an exception during the operation, it will be caught by the try-except block in the manager and the statuses of cgsnapshot and all snapshots will be set to ‘error’.

For a successful operation, the driver can either build the model_update and snapshots_model_update and return them or return None, None. The statuses of cgsnapshot and all snapshots will be set to ‘available’ at the end of the manager function.

create_consistencygroup(context, group)¶

Creates a consistencygroup.

Parameters:	context – the context of the caller. group – the dictionary of the consistency group to be created.
Returns:	model_update

model_update will be in this format: {‘status’: xxx, ......}.

If the status in model_update is ‘error’, the manager will throw an exception and it will be caught in the try-except block in the manager. If the driver throws an exception, the manager will also catch it in the try-except block. The group status in the db will be changed to ‘error’.

For a successful operation, the driver can either build the model_update and return it or return None. The group status will be set to ‘available’.

create_consistencygroup_from_src(context, group, volumes, cgsnapshot=None, snapshots=None, source_cg=None, source_vols=None)¶

Creates a consistencygroup from source.

Parameters:

context – the context of the caller.
group – the dictionary of the consistency group to be created.
volumes – a list of volume dictionaries in the group.
cgsnapshot – the dictionary of the cgsnapshot as source.
snapshots – a list of snapshot dictionaries in the cgsnapshot.
source_cg – the dictionary of a consistency group as source.
source_vols – a list of volume dictionaries in the source_cg.

Returns:

model_update, volumes_model_update

The source can be cgsnapshot or a source cg.

param volumes is retrieved directly from the db. It is a list of cinder.db.sqlalchemy.models.Volume to be precise. It cannot be assigned to volumes_model_update. volumes_model_update is a list of dictionaries. It has to be built by the driver. An entry will be in this format: {‘id’: xxx, ‘status’: xxx, ......}. model_update will be in this format: {‘status’: xxx, ......}.

To be consistent with other volume operations, the manager will assume the operation is successful if no exception is thrown by the driver. For a successful operation, the driver can either build the model_update and volumes_model_update and return them or return None, None.

delete_cgsnapshot(context, cgsnapshot, snapshots)¶

Deletes a cgsnapshot.

Parameters:	context – the context of the caller. cgsnapshot – the dictionary of the cgsnapshot to be deleted. snapshots – a list of snapshot dictionaries in the cgsnapshot.
Returns:	model_update, snapshots_model_update

param snapshots is retrieved directly from the db. It is a list of cinder.db.sqlalchemy.models.Snapshot to be precise. It cannot be assigned to snapshots_model_update. snapshots_model_update is a list of dictionaries. It has to be built by the driver. An entry will be in this format: {‘id’: xxx, ‘status’: xxx, ......}. model_update will be in this format: {‘status’: xxx, ......}.

The driver should populate snapshots_model_update and model_update and return them.

The manager will check snapshots_model_update and update db accordingly for each snapshot. If the driver successfully deleted some snapshots but failed to delete others, it should set statuses of the snapshots accordingly so that the manager can update db correctly.

If the status in any entry of snapshots_model_update is ‘error_deleting’ or ‘error’, the status in model_update will be set to the same if it is not already ‘error_deleting’ or ‘error’.

If the status in model_update is ‘error_deleting’ or ‘error’, the manager will raise an exception and the status of cgsnapshot will be set to ‘error’ in the db. If snapshots_model_update is not returned by the driver, the manager will set the status of every snapshot to ‘error’ in the except block.

If the driver raises an exception during the operation, it will be caught by the try-except block in the manager and the statuses of cgsnapshot and all snapshots will be set to ‘error’.

For a successful operation, the driver can either build the model_update and snapshots_model_update and return them or return None, None. The statuses of cgsnapshot and all snapshots will be set to ‘deleted’ after the manager deletes them from db.

delete_consistencygroup(context, group, volumes)¶

Deletes a consistency group.

Parameters:	context – the context of the caller. group – the dictionary of the consistency group to be deleted. volumes – a list of volume dictionaries in the group.
Returns:	model_update, volumes_model_update

param volumes is retrieved directly from the db. It is a list of cinder.db.sqlalchemy.models.Volume to be precise. It cannot be assigned to volumes_model_update. volumes_model_update is a list of dictionaries. It has to be built by the driver. An entry will be in this format: {‘id’: xxx, ‘status’: xxx, ......}. model_update will be in this format: {‘status’: xxx, ......}.

The driver should populate volumes_model_update and model_update and return them.

The manager will check volumes_model_update and update db accordingly for each volume. If the driver successfully deleted some volumes but failed to delete others, it should set statuses of the volumes accordingly so that the manager can update db correctly.

If the status in any entry of volumes_model_update is ‘error_deleting’ or ‘error’, the status in model_update will be set to the same if it is not already ‘error_deleting’ or ‘error’.

If the status in model_update is ‘error_deleting’ or ‘error’, the manager will raise an exception and the status of the group will be set to ‘error’ in the db. If volumes_model_update is not returned by the driver, the manager will set the status of every volume in the group to ‘error’ in the except block.

If the driver raises an exception during the operation, it will be caught by the try-except block in the manager. The statuses of the group and all volumes in it will be set to ‘error’.

For a successful operation, the driver can either build the model_update and volumes_model_update and return them or return None, None. The statuses of the group and all volumes will be set to ‘deleted’ after the manager deletes them from db.

update_consistencygroup(context, group, add_volumes=None, remove_volumes=None)¶

Updates a consistency group.

Parameters:	context – the context of the caller. group – the dictionary of the consistency group to be updated. add_volumes – a list of volume dictionaries to be added. remove_volumes – a list of volume dictionaries to be removed.
Returns:	model_update, add_volumes_update, remove_volumes_update

model_update is a dictionary that the driver wants the manager to update upon a successful return. If None is returned, the manager will set the status to ‘available’.

add_volumes_update and remove_volumes_update are lists of dictionaries that the driver wants the manager to update upon a successful return. Note that each entry requires a {‘id’: xxx} so that the correct volume entry can be updated. If None is returned, the volume will remain its original status. Also note that you cannot directly assign add_volumes to add_volumes_update as add_volumes is a list of cinder.db.sqlalchemy.models.Volume objects and cannot be used for db update directly. Same with remove_volumes.

If the driver throws an exception, the status of the group as well as those of the volumes to be added/removed will be set to ‘error’.

Generic Volume Groups¶

The generic volume groups feature provides the ability to manage a group of volumes together. Because this feature is implemented at the manager level, every driver gets this feature by default. If a driver wants to override the default behavior to support additional functionalities such as consistent group snapshot, the following interface must be implemented by the driver. Once every driver supporting volume consistency groups has added the consistent group snapshot capability to generic volume groups, we no longer need the volume consistency groups interface listed above.

Generic volume group volume driver interface.

class VolumeGroupDriver¶

Interface for drivers that support groups.

create_group(context, group)¶

Creates a group.

Parameters:	context – the context of the caller. group – the Group object to be created.
Returns:	model_update

model_update will be in this format: {‘status’: xxx, ......}.

If the status in model_update is ‘error’, the manager will throw an exception and it will be caught in the try-except block in the manager. If the driver throws an exception, the manager will also catch it in the try-except block. The group status in the db will be changed to ‘error’.

For a successful operation, the driver can either build the model_update and return it or return None. The group status will be set to ‘available’.

create_group_from_src(context, group, volumes, group_snapshot=None, snapshots=None, source_group=None, source_vols=None)¶

Creates a group from source.

Parameters:	context – the context of the caller. group – the Group object to be created. volumes – a list of Volume objects in the group. group_snapshot – the GroupSnapshot object as source. snapshots – a list of Snapshot objects in the group_snapshot. source_group – a Group object as source. source_vols – a list of Volume objects in the source_group.
Returns:	model_update, volumes_model_update

The source can be group_snapshot or a source group.

param volumes is a list of objects retrieved from the db. It cannot be assigned to volumes_model_update. volumes_model_update is a list of dictionaries. It has to be built by the driver. An entry will be in this format: {‘id’: xxx, ‘status’: xxx, ......}. model_update will be in this format: {‘status’: xxx, ......}.

To be consistent with other volume operations, the manager will assume the operation is successful if no exception is thrown by the driver. For a successful operation, the driver can either build the model_update and volumes_model_update and return them or return None, None.

create_group_snapshot(context, group_snapshot, snapshots)¶

Creates a group_snapshot.

Parameters:	context – the context of the caller. group_snapshot – the GroupSnapshot object to be created. snapshots – a list of Snapshot objects in the group_snapshot.
Returns:	model_update, snapshots_model_update

param snapshots is a list of Snapshot objects. It cannot be assigned to snapshots_model_update. snapshots_model_update is a list of dictionaries. It has to be built by the driver. An entry will be in this format: {‘id’: xxx, ‘status’: xxx, ......}. model_update will be in this format: {‘status’: xxx, ......}.

The driver should populate snapshots_model_update and model_update and return them.

The manager will check snapshots_model_update and update db accordingly for each snapshot. If the driver successfully deleted some snapshots but failed to delete others, it should set statuses of the snapshots accordingly so that the manager can update db correctly.

If the status in any entry of snapshots_model_update is ‘error’, the status in model_update will be set to the same if it is not already ‘error’.

If the status in model_update is ‘error’, the manager will raise an exception and the status of group_snapshot will be set to ‘error’ in the db. If snapshots_model_update is not returned by the driver, the manager will set the status of every snapshot to ‘error’ in the except block.

If the driver raises an exception during the operation, it will be caught by the try-except block in the manager and the statuses of group_snapshot and all snapshots will be set to ‘error’.

For a successful operation, the driver can either build the model_update and snapshots_model_update and return them or return None, None. The statuses of group_snapshot and all snapshots will be set to ‘available’ at the end of the manager function.

delete_group(context, group, volumes)¶

Deletes a group.

Parameters:	context – the context of the caller. group – the Group object to be deleted. volumes – a list of Volume objects in the group.
Returns:	model_update, volumes_model_update

param volumes is a list of objects retrieved from the db. It cannot be assigned to volumes_model_update. volumes_model_update is a list of dictionaries. It has to be built by the driver. An entry will be in this format: {‘id’: xxx, ‘status’: xxx, ......}. model_update will be in this format: {‘status’: xxx, ......}.

The driver should populate volumes_model_update and model_update and return them.

The manager will check volumes_model_update and update db accordingly for each volume. If the driver successfully deleted some volumes but failed to delete others, it should set statuses of the volumes accordingly so that the manager can update db correctly.

If the status in any entry of volumes_model_update is ‘error_deleting’ or ‘error’, the status in model_update will be set to the same if it is not already ‘error_deleting’ or ‘error’.

If the status in model_update is ‘error_deleting’ or ‘error’, the manager will raise an exception and the status of the group will be set to ‘error’ in the db. If volumes_model_update is not returned by the driver, the manager will set the status of every volume in the group to ‘error’ in the except block.

If the driver raises an exception during the operation, it will be caught by the try-except block in the manager. The statuses of the group and all volumes in it will be set to ‘error’.

For a successful operation, the driver can either build the model_update and volumes_model_update and return them or return None, None. The statuses of the group and all volumes will be set to ‘deleted’ after the manager deletes them from db.

delete_group_snapshot(context, group_snapshot, snapshots)¶

Deletes a group_snapshot.

Parameters:	context – the context of the caller. group_snapshot – the GroupSnapshot object to be deleted. snapshots – a list of Snapshot objects in the group_snapshot.
Returns:	model_update, snapshots_model_update

param snapshots is a list of objects. It cannot be assigned to snapshots_model_update. snapshots_model_update is a list of of dictionaries. It has to be built by the driver. An entry will be in this format: {‘id’: xxx, ‘status’: xxx, ......}. model_update will be in this format: {‘status’: xxx, ......}.

The driver should populate snapshots_model_update and model_update and return them.

The manager will check snapshots_model_update and update db accordingly for each snapshot. If the driver successfully deleted some snapshots but failed to delete others, it should set statuses of the snapshots accordingly so that the manager can update db correctly.

If the status in any entry of snapshots_model_update is ‘error_deleting’ or ‘error’, the status in model_update will be set to the same if it is not already ‘error_deleting’ or ‘error’.

If the status in model_update is ‘error_deleting’ or ‘error’, the manager will raise an exception and the status of group_snapshot will be set to ‘error’ in the db. If snapshots_model_update is not returned by the driver, the manager will set the status of every snapshot to ‘error’ in the except block.

If the driver raises an exception during the operation, it will be caught by the try-except block in the manager and the statuses of group_snapshot and all snapshots will be set to ‘error’.

For a successful operation, the driver can either build the model_update and snapshots_model_update and return them or return None, None. The statuses of group_snapshot and all snapshots will be set to ‘deleted’ after the manager deletes them from db.

update_group(context, group, add_volumes=None, remove_volumes=None)¶

Updates a group.

Parameters:	context – the context of the caller. group – the Group object to be updated. add_volumes – a list of Volume objects to be added. remove_volumes – a list of Volume objects to be removed.
Returns:	model_update, add_volumes_update, remove_volumes_update

model_update is a dictionary that the driver wants the manager to update upon a successful return. If None is returned, the manager will set the status to ‘available’.

add_volumes_update and remove_volumes_update are lists of dictionaries that the driver wants the manager to update upon a successful return. Note that each entry requires a {‘id’: xxx} so that the correct volume entry can be updated. If None is returned, the volume will remain its original status. Also note that you cannot directly assign add_volumes to add_volumes_update as add_volumes is a list of volume objects and cannot be used for db update directly. Same with remove_volumes.

If the driver throws an exception, the status of the group as well as those of the volumes to be added/removed will be set to ‘error’.

OpenStack

Drivers¶

Basic attributes¶

Minimum Features¶

Core Functionality¶

Volume Stats¶

Feature Enforcement¶

Driver Development Documentations¶

Base Driver Interface¶

Snapshot Interface¶

Manage/Unmanage Support¶

Manage/Unmanage Snapshot Support¶

Volume Consistency Groups¶

Generic Volume Groups¶

Table Of Contents

Previous topic

Next topic

Project Source

This Page

OpenStack

Drivers¶

Basic attributes¶

Minimum Features¶

Core Functionality¶

Volume Stats¶

Feature Enforcement¶

Driver Development Documentations¶

Base Driver Interface¶

Snapshot Interface¶

Manage/Unmanage Support¶

Manage/Unmanage Snapshot Support¶

Volume Consistency Groups¶

Generic Volume Groups¶

Table Of Contents

Previous topic

Next topic

Project Source

This Page

Quick search