[Openstack] [GLANCE] Proposal: Combine the "container_format" and "disk_format" fields in 2.0 Images API

Soren Hansen soren at linux2go.dk
Tue Dec 6 21:22:18 UTC 2011

2011/12/6 Jay Pipes <jaypipes at gmail.com>:
> On Fri, Dec 2, 2011 at 3:48 AM, Soren Hansen <soren at linux2go.dk> wrote:
>> 2011/12/1 Jay Pipes <jaypipes at gmail.com>:
>> There are basically two things that are relevant: The image type and the
>> container format.
>> The image type can be either of kernel, ramdisk, filesystem, iso9660,
>> disk, or "other".
> What value does "other" give the caller?

It's meant to denote something that isn't a kernel, ramdisk, filesystem,
iso9660, nor disk. Maybe swap space, maybe a raw block device for
Oracle.. Something that's distinct from the other things, but isn't
common enough to warrant its own designation.

>> The container type can be: raw, cow, qcow, qcow2, vhd, vmdk, vdi or qed
>> (and probably others I've forgotten).
> What about OVA? As I understand it, OVA is the single, tar'd file
> format that may store one or more virtual appliances that are in
> formats like VHD.

I consider that a transport format. Maybe my choice of nomenclature is
off, but an OVA clearly (based on your description) holds a number of
<something>s which in turn holds (typically) disk images.

I'd much rather if Glance would extract all the relevant information
from the OVA, store the disk images (setting the appropriate type and
format in the process) and then discard the OVA. Much like how we treat
ami's. It's a transport format.

> How does the following sound? Would this work for folks?
> type field, with the following possible values:
> * kernel
> * filesystem
> * ramdisk
> * disk
> * iso9660

Sure, I can live without the "other" type.
> format field, with the following possible values:
> * raw - This is an unstructured disk image format
> * qcow2 - A disk format supported by the QEMU emulator that can expand
> dynamically and supports Copy on Write

(Already responded about OVA).

You're missing qed, qemu's next gen disk format.

> Should there be another format value of:
> * iso - An archive format for the data contents of an optical disc (e.g. CDROM).
> to correspond to the iso9660 type?

No, "iso" isn't a format in the same sense as vmdk and qcow2, etc.

> Or should images with the iso9660 type have a "raw" format value?

Yes, your garden variety .iso is a raw formatted iso9660 filesystem. It
could technically be converted to any of the other formats, but seeing
as they're tightly packed (no need for sparseness) and read-only (no
need for sparseness nor copy-on-write), there's rarely much gained from
that (other then confusion).

Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/

More information about the Openstack mailing list