Package: datera-cinder
Datera Cinder Volume Driver Installation1. Clone Repository ``git clone http://github.com/Datera/cinder-driver``
2. Copy Driver ``cd cinder-driver && cp src/datera/*.py /usr/local/lib/pythonX.X/dist-packages/cinder/volume/drivers/datera``
3. Install Python-SDK ``sudo pip install -U dfs_sdk``
4. Modify ``/etc/cinder/cinder.conf``
  * Under [DEFAULT]
    * ``default_volume_type = datera``
    * ``enabled_backends = datera``
    * ``debug = True``
  * Under [datera]
    * ``volume_driver = cinder.volume.drivers.datera.datera_iscsi.DateraDriver``
    * ``san_ip = <datera_mgmt_ip>``
    * ``san_login = <datera_username>``
    * ``san_password = <datera_password>``
    * ``volume_backend_name = datera``
    * ``datera_tenant_id = <datera_tenant>``
4. Restart Cinder ``service cinder-volume restart``If you get an error like:ImportError: No module named dfs_sdkThen you can install the Python-SDK manually via$ pip install -U dfs_sdkDatera Volume Driver Version HistoryVersion History for Datera Volume DriverVersionChanges2019.2.25.0Scalability fixes and utility script updates2019.1.24.0Python-SDK requirements update, README updates2018.11.14.0Bugfixes for v2.1 API support and unicode character support2018.11.8.0Fixing bug that broke 2.2.X support2018.11.1.0Added flash and hybrid capacity info to get_volume_stats2018.10.30.0Adding template_override support.  Added datera_disable_template_override cfgOpt to disable this feature.  Updated required requests version to >=2.20.0 because of a security vulnerability in <=2.19.X.  Added support for filter_function and goodness_function.2018.10.8.1Adding thread_local to Python-SDK constructor call. This preserves trace_id in the logs2018.10.8.0Added extra_headers to Python-SDK constructor call.  This allows for the SDK to send the type of driver performing each request along with the request.  This functionality existed before the Python-SDK revamp, so this change adds the functionality back in.2018.9.17.0Readme and requirements.txt changes2018.7.13.0Massive update porting to use the Datera Python-SDK2018.6.7.0Bugfix for missing project_id during image clone2018.5.18.0Bugfix for None tenant handling2018.5.1.0Bugfix for Map tenant auto-creation2018.4.27.0Major driver revamp/restructure, no functionality change2018.4.17.1Bugfixes to IP Pools, Templates and Initiators2018.4.5.0Switch to new date-based versioning scheme.  Removed v2 API support2.9.2Made ensure_export a no-op.  Removed usage of initiator-groups2.9.1Added extended metadata attributes during volume creation and attachment.  Added datera_disable_extended_metadata option to disable it.2.9.0Volumes now correctly renamed during backend migration. Implemented update_migrated_volume (API 2.1+ only)2.8.7Bugfix for missing tenancy calls in offline_flip2.8.6Added LDAP support and CHAP support2.8.5Membership check for fast image cloning. Metadata API pinning2.8.4Fixed missing API version pinning in _offline_flip2.8.3Bugfix for not allowing fast clones for shared/community volumes2.8.2Updated most retype operations to not detach volume2.8.1Bugfix for missing default dict during retype2.8.0LDAP Support2.7.2Allowing DF: QoS Spec prefix, QoS type leak bugfix2.7.0IOPS/GB and BW/GB settings, driver level overrides2.6.1Glance interoperability fix2.6.0Api 2.2 support2.5.0Glance Image Caching, retyping/QoS bugfixes2.4.0Fast Retype Support2.3.2Volume Placement, ACL multi-attach bugfix2.3.1Scalability bugfixes2.3Templates, Tenants, Snapshot Polling, 2.1 Api Version Support, Restructure2.2Capabilites List, Extended Volume-Type Support Naming convention change, Volume Manage/Unmanage support2.1Multipath, ACL and reorg2.0Update For Datera API v21.1Look for lun-0 instead of lun-1.1.0Initial driverVolume Driver Cinder.conf OptionsDescription of Datera volume driver configuration optionsConfiguration option = Default valueDescriptionsan_ip=None(String) The IP address of the Datera management interface (REQUIRED)san_login=None(String) The username of the Datera account (REQUIRED)san_password=None(String) The password of the Datera account (REQUIRED)use_chap_auth=False(Bool) Set to True for CHAP authenticationchap_username=None(String) Username to use for CHAP authentication with ISCSI volumeschap_password=None(String) Password to use for CHAP authentication with ISCSI volumesdriver_client_cert_key=None(String) The path to the client certificate key for verification, if the driver supports it.datera_503_timeout=120(Int) Timeout for HTTP 503 retry messagesdatera_503_interval=5(Int) Interval between 503 retriesdatera_ldap_server=None(String) LDAP authentication serverdatera_debug=False(Bool) True to set function arg and return loggingdatera_debug_replica_count_override=False(Bool) True to set replica_count to 1datera_tenant_id=None(String) If set to ‘Map’ –> OpenStack project ID will be mapped implicitly to Datera tenant ID. If set to ‘None’ –> Datera tenant ID will not be used during volume provisioning. If set to anything else –> Datera tenant ID will be the provided valuedatera_disable_profiler=False(Bool) Set to True to disable profiling in the Datera driverdatera_volume_type_defaults=None(Dict) Settings here will be used as volume-type defaults if the volume-type setting is not provided.  This can be used, for example, to set a very low total_iops_max value if none is specified in the volume-type to prevent accidental overusage.  Options are specified via the following format, WITHOUT ANY ‘DF:’ PREFIX: ‘datera_volume_type_defaults= iops_per_gb:100,bandwidth_per_gb:200…etc’datera_enable_image_cache=False(Bool) Set to True to enable Datera backend image cachingdatera_image_cache_volume_type_id=None(String) Cinder volume type id to use for cached imagesVolume-Type ExtraSpecsDescription of Datera volume-type extra specsConfiguration option = Default valueDescriptionDF:replica_count=3(Int) Specifies number of replicas for each volume. Can only increase, never decrease after volume creationDF:round_robin=False(Bool) True to round robin the provided portals for a targetDF:placement_mode=hybrid(Bool) True to set acl ‘allow_all’ on volume created.  Cannot be changed on volume once setDF:ip_pool=default(String) Specifies IP pool to use for volumeDF:template=""(String) Specifies Datera Template to use for volume provisioningDF:default_storage_name=storage-1(String) The name to use for storage instances createdDF:default_volume_name=volume-1(String) The name to use for volumes createdDF:read_bandwidth_max=0(Int) Max read bandwidth setting for volume QoS.  Use 0 for unlimitedDF:write_bandwidth_max=0(Int) Max write bandwidth setting for volume QoS.  Use 0 for unlimitedDF:total_bandwidth_max=0(Int) Total write bandwidth setting for volume QoS.  Use 0 for unlimitedDF:read_iops_max=0(Int) Max read IOPS setting for volume QoS.  Use 0 for unlimitedDF:write_iops_max=0(Int) Max write IOPS setting for volume QoS.  Use 0 for unlimitedDF:total_iops_max=0(Int) Total write IOPS setting for volume QoS.  Use 0 for unlimitedDF:iops_per_gb=0(Int) IOPS per GB of data allocated for the volume.  If this value exceeds the total_max_iops value, the total_max_iops will be used insteadDF:bandwidth_per_gb=0(Int) Bandwidth (KB/s) per GB of data allocated for the volume.  If this value exceeds the total_max_bandwidth value, the total_max_bandwidth will be used insteadCollecting Logs for OpenStack CinderIf for some reason there is a problem with the OpenStack Cinder driver.  You
MUST collect the cinder-volume service logs.  Without logs, debugging issues
is significantly more difficult.The location of the cinder-volume logs varies between installations but here
are a few places to check:/var/log/cinder/opt/stack/cinderjournalctl -u cinder-volumeThese places are usually only valid on the controller node running the
cinder-volume serviceIf they’re not in any of the above places you will have to look into where
the service is saving logs.  Often they will be inside a container for the
service.Datera Cinder Backup Version HistoryDatera Backup Driver VersionsVersionChanges1.0Initial driverBackup Driver Cinder.conf OptionsDescription of Datera backup driver configuration optionsConfiguration option = Default valueDescriptionbackup_datera_san_ip=None(Required) (String) Datera EDF Mgmt IPbackup_datera_san_login=None(Required) (String) Datera EDF Usernamebackup_datera_san_password=None(Required) (String) Datera EDF Passwordbackup_datera_tenant_id=/root(Required) (String) Datera EDF Tenantbackup_datera_chunk_size=1(Int) Total chunk size (in GB, min 1 GB) to use for backupbackup_datera_progress_timer=False(Bool) Enable progress timer for backupbackup_datera_replica_count=3(Int) Number of replicas for each backup containerbackup_datera_placement_mode=hybrid(String) Options: hybrid, single_flash, all_flashbackup_datera_api_port=7717(String) Datera EDF API portbackup_datera_secondary_backup_drivers= [](List) Secondary backup drivers for the Datera EDF driver to manageBackup Driver Dispatching/MultiplexingAs of backup driver version 1.0.1 we allow for managing multiple secondary
backup driver backends.  Vanilla Cinder supports only a single backup driver
backend in an OpenStack cluster.  We’ve added backup driver dispatching to the
Datera EDF backup driver to allow for multiple backup driver backends to be used
along side the Datera EDF backup driver backend.To utilize this function, set the following in your cinder.conf:backup_datera_secondary_backup_drivers=your.backup.driver.moduleIf you wanted to use Ceph, you would set this to:backup_datera_secondary_backup_drivers=cinder.backup.drivers.cephYou would then use the following naming convention to select which backend you
want to store the backup on:openstackvolumebackupcreateyour_volume--name<driver_module>_you_backup_nameWhere <driver_module> is replaced by the module of the driver you want to use.
In the case of Ceph it would be “ceph”.  Example:openstackvolumebackupcreatehadoop1--nameceph_hadoop1_backupIf no name is specified the Datera EDF driver will be used, but you can also use
the following to manually specify the Datera EDF backup driver:openstackvolumebackupcreatecassandra1--namedatera_cassandra1_backup