The cinder.volume.drivers.hpe.hpe_3par_base Module

The cinder.volume.drivers.hpe.hpe_3par_base Module

Base class for HPE Storage Drivers. This driver requires 3.1.3 or later firmware on the 3PAR array, using the 4.x version of the hpe3parclient.

You will need to install the python hpe3parclient. sudo pip install –upgrade “hpe3parclient>=4.0”

class HPE3PARDriverBase(*args, **kwargs)

Bases: cinder.volume.driver.ManageableVD, cinder.volume.driver.ManageableSnapshotsVD, cinder.volume.driver.MigrateVD, cinder.volume.driver.BaseVD

OpenStack base driver to enable 3PAR storage array.

Version history:

1.0.0 - Initial base driver
1.0.1 - Adds consistency group capability in generic volume groups.
1.0.2 - Adds capability.
1.0.3 - Added Tiramisu feature on 3PAR.
1.0.4 - Fixed Volume migration for "in-use" volume. bug #1744021
VERSION = '1.0.4'
check_for_setup_error()

Setup errors are already checked for in do_setup so return pass.

create_cloned_volume(volume, src_vref)

Clone an existing volume.

create_export(context, volume, connector)

Exports the volume.

Can optionally return a Dictionary of changes to the volume object to be persisted.

create_group(context, group)

Creates a group.

Parameters:
  • context – the context of the caller.
  • group – the Group object of the 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_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 group_snapshot.
  • source_group – the 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.

create_snapshot(snapshot)
create_volume(volume)

Creates a volume.

Can optionally return a Dictionary of changes to the volume object to be persisted.

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

volume['replication_status'] = 'copying'
volume['replication_extended_status'] = <driver specific value>
volume['driver_data'] = <driver specific value>
create_volume_from_snapshot(volume, snapshot)

Creates a volume from a snapshot.

TODO: support using the size from the user.

delete_group(context, group, volumes)

Deletes a group.

Parameters:
  • context – the context of the caller.
  • group – the Group object of the group 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.

delete_snapshot(snapshot)
delete_volume(volume)

Deletes a volume.

If volume_type extra specs includes ‘replication: <is> True’ then the driver needs to delete the volume replica too.

disable_replication(context, group, volumes)

Disable replication for a group.

Parameters:
  • context – the context
  • group – the group object
  • volumes – the list of volumes
Returns:

model_update, None

do_setup(context)

Any initialization the volume driver does while starting.

enable_replication(context, group, volumes)

Enable replication for a group.

Parameters:
  • context – the context
  • group – the group object
  • volumes – the list of volumes
Returns:

model_update, None

ensure_export(context, volume)

Synchronously recreates an export for a volume.

extend_volume(volume, new_size)
failover_host(context, volumes, secondary_id=None, groups=None)

Force failover to a secondary replication target.

failover_replication(context, group, volumes, secondary_backend_id=None)

Failover replication for a group.

Parameters:
  • context – the context
  • group – the group object
  • volumes – the list of volumes
  • secondary_backend_id – the secondary backend id - default None
Returns:

model_update, vol_model_updates

get_pool(volume)

Return pool name where volume reside on.

Parameters:volume – The volume hosted by the driver.
Returns:name of the pool where given volume is in.
get_volume_stats(refresh=False)

Return the current state of the volume service.

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

For replication the following state should be reported: replication = True (None or false disables replication)

initialize_connection(volume, connector)

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.
Returns conn_info:
 

A dictionary of connection information.

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
Returns size:

Volume size in GiB (integer)

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.

Parameters:
  • snapshot – Cinder volume snapshot to manage
  • existing_ref – Driver-specific information used to identify a volume snapshot
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 – Cinder volume snapshot to manage
  • existing_ref – Driver-specific information used to identify a volume snapshot
Returns size:

Volume snapshot size in GiB (integer)

migrate_volume(context, volume, host)

Migrate the volume to the specified host.

Returns a boolean indicating whether the migration occurred, as well as model_update.

Parameters:
  • context – Context
  • volume – A dictionary describing the volume to migrate
  • 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.
remove_export(context, volume)

Removes an export for a volume.

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

Convert the volume to be of the new type.

revert_to_snapshot(context, volume, snapshot)

Revert volume to snapshot.

terminate_connection(volume, connector, **kwargs)

Disallow connection from connector.

Parameters:
  • volume – The volume to be disconnected.
  • connector – A dictionary describing the connection with details about the initiator. Can be None.
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.

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 – Cinder volume snapshot to unmanage
update_group(context, group, add_volumes=None, remove_volumes=None)

Updates a group.

Parameters:
  • context – the context of the caller.
  • group – the Group object of the group 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’.

update_migrated_volume(context, volume, new_volume, original_volume_status)

Update the name of the migrated volume to it’s new ID.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.