Jump to: navigation, search

Difference between revisions of "EfficientVolumesFromImage"

 
m (Text replace - "NovaSpec" to "NovaSpec")
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
__NOTOC__
+
* '''Launchpad Entry''': NovaSpec:efficient-volumes-from-images
* '''Launchpad Entry''': [[NovaSpec]]:efficient-volumes-from-images
 
 
* '''Created''': 03 April 2012
 
* '''Created''': 03 April 2012
 
* '''Contributors''': Josh Durgin, Tommi Virtanen
 
* '''Contributors''': Josh Durgin, Tommi Virtanen
Line 37: Line 36:
  
 
== Design ==
 
== Design ==
 +
[[Image:cow_volume_from_image.png]]
  
 
== Implementation ==
 
== Implementation ==

Latest revision as of 23:31, 17 February 2013

  • Launchpad Entry: NovaSpec:efficient-volumes-from-images
  • Created: 03 April 2012
  • Contributors: Josh Durgin, Tommi Virtanen

Summary

Make volume (and instance) creation fast if Nova volumes and Glance use the same storage backend, and the storage backend supports it.

Release Note

Instance and volume creation can take advantage of underlying storage to be more efficient in space and time.

Rationale

Storage systems offer a number of features that can save space and time when storing both images and volumes:

  • features like copy-on-write can be used to make volume (and instance creation) near-instantaneous and save space
  • deduplication can happen on images and volumes together, reducing hardware requirements
  • administrators only have to maintain one storage system

User stories

User creates a bunch of new instances that have no ephemeral disks, but are all based on the same image. This happens very quickly due to a shared underlying storage system, and requires very little extra space.

Assumptions

Depends on create-volume-from-image and a way to query Glance about the backing store of an image.

Design

Cow volume from image.png

Implementation

There are two parts that are volume backend dependent:

  1. determining whether a given image is stored on the same backend as volumes
  2. efficiently creating a volume based on the image

These can both be optional volume driver methods - something like `def cloneable(image_info)` and `def clone(image_info, volume_name)` - if they aren't implemented, or cloneable returns false, fallback to the open/write/close api from create-volume-from-image.

Migration

No database or core API changes.

Test/Demo Plan

This need not be added or completed until the specification is nearing beta.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.