Bug 1041673

Summary: [RFE][cinder]: Add a driver_id field to Volumes for use by drivers as an internal reference to backing storage.
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/cinder/+spec/volume-driver-id
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_obsolete
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 16:51:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 18:35:49 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/cinder/+spec/volume-driver-id.

Description:

This blueprint proposes the addition of a new driver_id field to the Cinder Volume table, which can be used to store a driver-specific reference to the backing storage used by a Volume.

The benefits of the blueprint are:

1.	Cinder drivers that are capable of “naming” the resource associated with a Cinder Volume (e.g. a disk on an external storage controller) are no longer required to embed the Cinder Volume UUID into that name, freeing up the name to be used for a friendlier purpose, such as reflecting the Cinder Volume’s display name.

2.	Higher performance and simpler code by allowing Cinder drivers to refer to their backing storage in a way that is most efficient and natural for them, rather than having to introduce a means of keying off the Cinder Volume UUID.  For example, in the Storwize V7000 driver, disks are currently named based on the Volume’s “name” property (which is of the form prefix-uuid), rather than the preferred internal Storwize Volume ID.

3.	Removing the requirement for backend storage to present itself in a certain way (e.g. for Storwize, with the correct disk name) in order to be consumable by OpenStack.  This capability simplifies the volume-migration blueprint, which may require that during migrations a given Cinder Volume must refer to multiple disks (and on some storage controllers, no two disks may have the same name).  It would also enable a possible future capability to “import” existing storage into Cinder without having to rename the backend disk.


Specification URL (additional information):

https://wiki.openstack.org/wiki/Blueprint-cinder-volume-driver-id