Adding a store driver to allow Cinder as a block storage backend for Glance
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-
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:
-
2013.2
- Started by
- Zhi Yan Liu
- Completed by
- Mark Washenberger
Related branches
Related bugs
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-
Long team (H3-):
1. cinder brick: https:/
2. volume-
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:/
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:/
-dperaza
This looks like something you could use for add implementation:
https:/
-dperaza
Work Items
Dependency tree
* Blueprints in grey have been implemented.
