The cinder.volume.drivers.dell.dell_storagecenter_common Module

class DellCommonDriver(*args, **kwargs)

Bases: cinder.volume.driver.ConsistencyGroupVD, cinder.volume.driver.ManageableVD, cinder.volume.driver.ExtendVD, cinder.volume.driver.ManageableSnapshotsVD, cinder.volume.driver.SnapshotVD, cinder.volume.driver.BaseVD

check_for_setup_error()

Validates the configuration information.

create_cgsnapshot(context, cgsnapshot, snapshots)

Takes a snapshot of the consistency group.

Parameters:

• context – the context of the caller.
• cgsnapshot – Information about the snapshot to take.
• snapshots – List of snapshots for this cgsnapshot.

Returns:

Updated model_update, snapshots.

Raises:

VolumeBackendAPIException.

create_cloned_volume(volume, src_vref)

Creates a clone of the specified volume.

create_consistencygroup(context, group)

This creates a replay profile on the storage backend.

Parameters:

• context – the context of the caller.
• group – the dictionary of the consistency group to be created.

Returns:

Nothing on success.

Raises:

VolumeBackendAPIException

create_export(context, volume, connector)

Create an export of a volume.

The volume exists on creation and will be visible on initialize connection. So nothing to do here.

create_snapshot(snapshot)

Create snapshot

create_volume(volume)

Create a volume.

create_volume_from_snapshot(volume, snapshot)

Create new volume from other volume’s snapshot on appliance.

delete_cgsnapshot(context, cgsnapshot, snapshots)

Deletes a cgsnapshot.

If profile isn’t found return success. If failed to delete the replay (the snapshot) then raise an exception.

Parameters:

• context – the context of the caller.
• cgsnapshot – Information about the snapshot to delete.

Returns:

Updated model_update, snapshots.

Raises:

VolumeBackendAPIException.

delete_consistencygroup(context, group, volumes)

Delete the Dell SC profile associated with this consistency group.

Parameters:

• context – the context of the caller.
• group – the dictionary of the consistency group to be created.

Returns:

Updated model_update, volumes.

delete_snapshot(snapshot)

delete_volume(volume)

do_setup(context)

One time driver setup.

Called once by the manager after the driver is loaded. Sets up clients, check licenses, sets up protocol specific helpers.

ensure_export(context, volume)

Ensure an export of a volume.

Per the eqlx driver we just make sure that the volume actually exists where we think it does.

extend_volume(volume, new_size)

Extend the size of the volume.

failback_volumes(volumes)

This is a generic volume failback.

Parameters:volumes – List of volumes that need to be failed back. Returns:volume_updates for the list of volumes.

failover_host(context, volumes, secondary_id=None)

Failover to secondary.

Parameters:

• context – security context
• secondary_id – Specifies rep target to fail over to
• volumes – List of volumes serviced by this backend.

Returns:

destssn, volume_updates data structure

Example volume_updates data structure:

[{‘volume_id’: <cinder-uuid>,

‘updates’: {‘provider_id’: 8,

‘replication_status’: ‘failed-over’, ‘replication_extended_status’: ‘whatever’,...}},]

get_volume_stats(refresh=False)

Get volume status.

If ‘refresh’ is True, run update the stats first.

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 – Driver-specific information used to identify a volume

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 – Driver-specific information used to identify a volume

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:

1. 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.
2. 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.

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

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.

remove_export(context, volume)

Remove an export of a volume.

We do nothing here to match the nothing we do in create export. Again we do everything in initialize and terminate connection.

retype(ctxt, volume, new_type, diff, host)

Convert the volume to be of the new type.

Returns a boolean indicating whether the retype occurred.

Parameters:

• ctxt – Context
• volume – A dictionary describing the volume to migrate
• new_type – A dictionary describing the volume type to convert to
• diff – A dictionary with the difference between the two types
• host – A dictionary describing the host to migrate to, where host[‘host’] is its name, and host[‘capabilities’] is a dictionary of its reported capabilities (Not Used).

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

unmanage_snapshot(snapshot)

Removes the specified snapshot from Cinder management.

Does not delete the underlying backend storage object.

NOTE: We do set the expire countdown to 1 day. Once a snapshot is

unmanaged it will expire 24 hours later.

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’.

update_migrated_volume(ctxt, volume, new_volume, original_volume_status)

Return model update for migrated volume.

Parameters:

• volume – The original volume that was migrated to this backend
• new_volume – The migration volume object that was created on this backend as part of the migration process
• original_volume_status – The status of the original volume

Returns:

model_update to update DB with any needed changes