openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

Hi Soren, thanks for your detailed input. Comments inline...

On Fri, Dec 2, 2011 at 3:48 AM, Soren Hansen <soren@xxxxxxxxxxx> wrote:
> 2011/12/1 Jay Pipes <jaypipes@xxxxxxxxx>:
>> 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".

What value does "other" give the caller?

> 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. It seems to me that people using OVA+VHD(s) would
appreciate a container_type of 'ova' for this purpose? The OVA file
may be untar'd locally and the OVF directory structure inside the OVA
would contain information about the virtual appliances contained in
the OVA. This means there would be no need for a MIME-like type such
as "ova/vhd" since the OVF directory inside the OVA would contain a
manifest that describes the virtual appliances.

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

Yep, agreed on all your points above.

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

Right. There's a bit more that goes on in Nova that involves the
nova-objectstore (that stores the manifest.xml files and image part
files created during the EC2 image processes). But those details are
tangential to this discussion. I agree with you that "kernel",
"ramdisk", and "filesystem" should replace the existing "ari", "aki",
and "ami" container and disk formats.

How does the following sound? Would this work for folks?

type field, with the following possible values:

* kernel
* filesystem
* ramdisk
* disk
* iso9660

format field, with the following possible values:

* raw - This is an unstructured disk image format
* 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. The OVA should be untar'd and
inspected to determine the disk format of the virtual appliances
contained within the OVA.
* 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
* qcow2 - A disk format supported by the QEMU emulator that can expand
dynamically and supports Copy on Write

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? Or should images with the iso9660
type have a "raw" format value?

-jay