Open Stack

2011/12/1 Jay Pipes <jaypipes at gmail.com>:
> structure tar'd up. However, I think this can be more easily
> accomplished by consolidating the disk and container formats in the
> 2.0 API to just a single format field with the possible values:
>
>    ova - This indicates the data stored in Glance is an OVF container
> that may actually contain multiple virtual appliances that has been
> tar'd into the single-file OVA format
>    raw - This is an unstructured disk image format
>    vhd - This is the VHD disk format, a common disk format used by
> virtual machine monitors from VMWare, Xen, Microsoft, VirtualBox, and
> others
>    vmdk - Another common disk format supported by many common virtual
> machine monitors
>    vdi - A disk format supported by VirtualBox virtual machine
> monitor and the QEMU emulator
>    iso - An archive format for the data contents of an optical disc
> (e.g. CDROM).
>    qcow2 - A disk format supported by the QEMU emulator that can
> expand dynamically and supports Copy on Write
>    aki - This indicates what is stored in Glance is an Amazon kernel image
>    ari - This indicates what is stored in Glance is an Amazon ramdisk image
>    ami - This indicates what is stored in Glance is an Amazon machine image
>
> What do people think of this proposal to combine the two into a single
> "format" field?

I agree the current "disk_format"/"container_format" tuple isn't ideal.
There's overlap between the two and at the same time, there are things
that can't be expressed with the current selection of valid settings. I
do think having two separate fields defining the contents, though.

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".

The container type can be: raw, cow, qcow, qcow2, vhd, vmdk, vdi or qed
(and probably others I've forgotten).

Container type is essential in deciding whether the hypervisor in
question will be able to take the image and read its contents (i.e. map
a block of data in the container to a block of data in the contained
image).  Image type is essential in deciding what to do with it. I.e.
*don't* try to attach a kernel as a filesystem, *don't* try to use an
iso9660 image as your kernel, *do* attach iso9660 images as CD's, not as
hard drives, *do* accept booting a VM with only a disk image attached,
*do* require a kernel if you have a filesystem image rather than a disk
image, etc. At the moment, we try to guess the user's intent (if they
don't pass a kernel, we just boot the image and hope for the best). This
is error prone.

"aki", "ari", and "ami" have always struck me as odd.  If you upload an
"aki" to OpenStack, by the time it actually reaches Glance, it's not an
aki anymore. Its image type is "kernel" and its container format is
"raw". It's indistinguishable from a raw kernel image uploaded by some
other mechanism. Same for ari (ramdisk/raw) and ami (filesystem/raw). If
anything, aki/ari/ami might be considered a (single) transport format.
Uploading an image to EC2 involves a bundling process where the image in
question is split up, signed (and encrypted?), uploaded to S3 along with
a manifest and then "registered". Upon registration, the signature is
verified, the image is decrypted(?), and stitched back together to form
a kernel image (or ramdisk or machine image). At this point, any
remnants of the manifest and the rest of the bundle are gone.

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