Golden Image Flow
An OpenStack user should be able to create images that work in their cloud with minimal knowledge of the implementation details of the cloud (hypervisor). This blueprint addresses how to design an image that supports of a wide variety of hypervisors.
Right now, users of OpenStack don't have any clear and consistent way to determine:
- how to create an image that the user can upload to the cloud
- what format their image should be to support multiple clouds (golden format)
By specifying a 'Golden' image interchange format, which all clouds must support, implementers will have a much narrower scope of work to enable image interoperability, and users will have much clearer direction on how to best interact with images when the goal is interoperability.
At this time, the natural 'Golden' format seems to be raw, since raw images are easy to create, read, and modify.
User Story
Tony wants to move an instance from vmware to OpenStack. First, he converts his image to the Golden Image Format (raw). He then uploads this image to an OpenStack cloud using glance client. Once the upload is complete, he then boots this image. After a month, Tony decides to move his instance to yet another cloud. He snapshots his image, exports that snapshot to the Golden format using glance client, uploads it to a different cloud, and then launches.
Details:
- User uploads raw[.gz?] image to glance (optionally support internal format although we want to encourage raw as the standard) in cloud.
- Nova-compute can convert to an optimized runtime format (if needed) at runtime.
- The user snapshots, which uploads the snapshot to glance - in either raw or internal format.
- The user can launch multiple copies of the snapshot.
- The user can download the snapshot (which is converted to raw on client)
Implementation
Assumptions:
- raw images are supported in all hypervisors
- kvm driver would create a qcow2 cow image backed to the raw image
- rax uses xs driver and would use VHD runtime images (raw converted to vhd?)
Questions:
- Since raw images are large, should we use gzipped raw images?
- Glance client would need work with qemu-img to convert back to raw? What about windows and osx support?
- Does our golden image support the disk-management changes (specifying root and ephemeral space independently in flavors)?
Citrix uses xs driver but prefers images _
- lxc driver uses ?
- Vmware driver uses ?
Questions pertaining to the nova hypervisor drivers:
- Can/should nova use the golden format internally, or should it convert to the preferred runtime format
- Can nova create snapshot of running images that allows re-launching
- Can a user (easily) convert the snapshot format back to original (golden) format? If so, how should that work?
Tasks:
- Document how to create golden images / provide examples to users
- Ensure hypervisors support golden image
- Ensure integration test coverage for flow
Post Essex User Flow
The flow is the same as previously specified, though some of the implementation details may push to the server side:
Details:
- User uploads raw[.gz?] image to glance (optionally support internal format although we want to encourage raw as the standard) in cloud
- Post ingestion glance converts to an optimized runtime format.
- The user snapshots, which uploads the snapshot to glance - in either raw or internal format.
- The user can launch multiple copies of the snapshot.
- The user can download the snapshot (which was converted to raw on service)