Adding a store driver to allow Cinder as a block storage backend for Glance

Registered by Zhi Yan Liu on 2013-03-05

We have a driver for swift as an object storage back-end in Glance, so make a block storage back-end is make sense to me, that is Cinder.

**Note**: Currently Cinder store is a partial implementation. After Cinder expose 'brick' library, and Readonly-volume-attaching', 'volume-multiple-attaching' enhancement ready, the store will support 'Upload' and 'Download' interface finally.

Draft:
Interfacing to cinderclient and creating a read only volume specifically for image store.
1. Create an image-store volume (special type volume that's R/O).
2. Store the glance image, and update glance to have a record of the image and it's location (specifically provider_location).
3. Copy can use the clone functionality which is especially great for back-ends with advanced cloning capability.

Blueprint information

Status:
Complete
Approver:
John Griffith
Priority:
Medium
Drafter:
Zhi Yan Liu
Direction:
Approved
Assignee:
Zhi Yan Liu
Definition:
Approved
Series goal:
Accepted for havana
Implementation:
Implemented
Milestone target:
milestone icon 2013.2
Started by
Zhi Yan Liu on 2013-06-13
Completed by
Mark Washenberger on 2013-07-17

Related branches

Sprints

Whiteboard

I'd still really like to see us move away from exposing efficient volume behaviors in glance, and instead focus on figuring out how to get nova to use cinder more effectively. But I think registering cinder volumes as images could be an acceptable way to deliver some good features more quickly.
-markwash

After more thought, this seems like a perfect fit, as expressing the full block device mapping for an instance seems like the direction Glance should go.
-markwash

For now the implementation for this blueprint has following dependencies:
Sort team (H2):
1. image-multiple-location: https://blueprints.launchpad.net/glance/+spec/multiple-image-locations
Long team (H3-):
1. cinder brick: https://blueprints.launchpad.net/cinder/+spec/cinder-refactor-attach
2. volume-host-attaching: https://blueprints.launchpad.net/cinder/+spec/volume-host-attaching
3. multiple-attaching:
for #3 we need concurrent control for the volume attaching and detaching code/behavior, because under multiple glance-api runtime, volume access under concurrent status, such as glance-api #A get volumeX size, and glance-api #B download (read) it, #A maybe finish early then #B read, so if #A detach the volume (iscsi session logout) on that time, #B will be failed.
  And more, the concurrent control for attaching and detaching logic is needed also to maintain the attached device status between the nova and glance when those components running on the same host.
  For example, a iscsi volume could be attached two times, one from glance-api process and one from nova-compute, but there is only one attached device in whole system ('/dev/sdc' file), and if glance-api detach and remove the attached device before nova-compute then nova will meet I/O error since the attached device been removed prematurely.
-zhiyan

  Addressed by: https://review.openstack.org/32864
      Adding Cinder backend storage driver to Glance

  Have you considered a path where glance does not have to attach and detach but instead call cinder API that would take an image glance url. Cinder should be the one with knowledge to move image they can get from glance like nova does and then stream into a pre-created volume. This could require a change in API for volume post in cinder. I found that cinder driver supports copy of glance images to volumes https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L170 and see this in API https://github.com/openstack/cinder/blob/master/cinder/api/v2/volumes.py#L300 so it could just work
-dperaza

This looks like something you could use for add implementation:
https://wiki.openstack.org/wiki/CreateVolumeFromImage
-dperaza

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.