The cinder.volume.drivers.dothill.dothill_iscsi Module

The cinder.volume.drivers.dothill.dothill_iscsi Module

class DotHillISCSIDriver(*args, **kwargs)

Bases: cinder.volume.driver.ISCSIDriver

OpenStack iSCSI cinder drivers for DotHill Arrays.

Version history:
    0.1    - Base structure for DotHill iSCSI drivers based on HPMSA FC
             drivers:
                 "https://github.com/openstack/cinder/tree/stable/juno/
                  cinder/volume/drivers/san/hp"
    1.0    - Version developed for DotHill arrays with the following
             modifications:
                 - added iSCSI support
                 - added CHAP support in iSCSI
                 - added support for v3 API(virtual pool feature)
                 - added support for retype volume
                 - added support for manage/unmanage volume
                 - added https support
    1.6    - Add management path redundancy and reduce load placed
             on management controller.
    1.7    - Modified so it can't be invoked except as a superclass
check_for_setup_error()
create_chap_record(initiator_name)
create_cloned_volume(volume, src_vref)

Creates a clone of the specified volume.

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.

create_export(context, volume, connector=None)

Exports the volume.

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

create_snapshot(snapshot)

Creates a 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, src_vref)

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.

delete_snapshot(snapshot)

Deletes a 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.

do_setup(context)

Any initialization the volume driver does while starting.

ensure_export(context, volume)

Synchronously recreates an export for a volume.

extend_volume(volume, new_size)
get_volume_stats(refresh=False)

Get volume stats.

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

initialize_connection(volume, connector)

Initializes the connection and returns connection info.

The iscsi driver returns a driver_volume_type of ‘iscsi’. The format of the driver data is defined in _get_iscsi_properties. Example return value:

{
    'driver_volume_type': 'iscsi',
    'data': {
        'target_discovered': True,
        'target_iqn': 'iqn.2010-10.org.openstack:volume-00000001',
        'target_portal': '127.0.0.0.1:3260',
        'volume_id': 1,
        'discard': False,
    }
}

If the backend driver supports multiple connections for multipath and for single path with failover, “target_portals”, “target_iqns”, “target_luns” are also populated:

{
    'driver_volume_type': 'iscsi',
    'data': {
        'target_discovered': False,
        'target_iqn': 'iqn.2010-10.org.openstack:volume1',
        'target_iqns': ['iqn.2010-10.org.openstack:volume1',
                        'iqn.2010-10.org.openstack:volume1-2'],
        'target_portal': '10.0.0.1:3260',
        'target_portals': ['10.0.0.1:3260', '10.0.1.1:3260'],
        'target_lun': 1,
        'target_luns': [1, 1],
        'volume_id': 1,
        'discard': False,
    }
}
initialize_iscsi_ports()
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)

remove_export(context, volume)

Removes an export for a volume.

retype(context, volume, new_type, diff, host)
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
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.