Open Stack

On Fri, 2 Dec 2011, Soren Hansen wrote:

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

I generally agree with Soren here, but Jay originally asked:

 | The problem I see is that really OVF is the only real "container
 | format" and I'm just not sure it's useful to have users set a
 | container format. The goal was to allow Glance to report that the
 | image file stored in Glance is an OVA file and not an image file
 | itself. An OVA file is a single file that contains the OVF directory
 | 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:

OVF is neither "container format", nor "image [content] type".
It is a thing that deals with a higher level object.  These things are
"VirtualSystems"  and "VirtualSystemCollections".

A "VirtualSystem" has "Disk" elements, which have an "ovf:format"
attribute which would contain a value describing the same thing as
"container type" above.

A "VirtualSystemCollection" defines a group of VirtualSystems and
relationships between them.

One thing Jay did not mention (which seems relevant to me) is that he
really described "OVA". "OVF" is a superset of OVA which additionally
describes a "set of files" description format, where you have the same ovf
manifest file, but 'File' elements have 'ovf:href=' attributes which can
be arbitrary uri.   The use of that could potentiall be a .ovf file stored
somewhere [possibly glance] with 'File' elements that reference glance://
files.  Almost certainly, though, if you *were* using OVF like that, you'd
need to have urls that referenced something other than "disk"s (such as
manifest file and language files.

Any way you look at it, OVF is definitely the oddball here, and I do not
think it really fits where it is put.

Is anything actually using OVA from glance?