2011/12/1 Jay Pipes <jaypi...@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/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
