Add a driver_id field to Volumes for use by drivers as an internal reference to backing storage.

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.