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

Registered by Geraint North

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.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
Alan Jiang
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Sean McGinnis

Related branches

Sprints

Whiteboard

(smcginnis): Marking obsolete as this has been sitting out there for a long time. If this is still needed, please submit a new bp.

I'm rather concerned that the blueprint suggests returning the driver id via the REST APIs. Except posisbly as an admin-only extention, we /really/ don't want to do this... Keep implementation details totally hidden from end users. --DuncanT

As I asked it here https://answers.launchpad.net/cinder/+question/240494 I got a good answer for that. You can use VolumeAdminMetadata a metadata that can be used store key-value pairs. So those who want driver_id to be store they can add driver_id key with corrousponding value. As DuncanT suggesting this value won't be visible in API calls. -Amol

The admin metadata would be visible in API calls from the originator, as it is merged with the existing metadata - would that be a problem? - Geraint

Admin Metadata won't be visible in API calls from the originator. - Amol

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.