Open Stack

On 23/01/16 09:08 -0800, Clint Byrum wrote:
>Excerpts from Brian Rosmaita's message of 2016-01-23 06:54:26 -0800:
>> Please provide feedback about a proposal to add 'tar' as a new Glance disk_format.[0]
>>
>> The Ironic team is adding support for "OS tarball images" in Mitaka.  This is a compressed tar archive of a / (root filesystem). These tarballs are created by first installing the OS packages in a chroot and then compressing the chroot as tar.*.  The proposal is to store such images as disk_format == tar and container_format == bare.
>>
>> Intuitively, 'tar' seems more like a container_format.  The Glance developer documentation, however, says that "The container format refers to whether the virtual machine image is in a file format that also contains metadata about the actual virtual machine."[1]  Under this proposal, there is no such metadata included.
>>
>> The Glance docs say this about disk_format: "The disk format of a virtual machine image is the format of the underlying disk image. Virtual appliance vendors have different formats for laying out the information contained in a virtual machine disk image."[1]  Under this definition, 'tar' as used in this proposal [0] does in fact seem to be a disk_format.
>>
>> There is not currently a 'tar' container format defined for Glance.  The closest we have now is 'ova' (an OVA tar archive file) and 'docker' (a Docker tar archive of the container filesystem).  And, in fact, 'tar' as a container format wouldn't be very helpful, as it doesn't indicate where in the tarball the metadata should be found.
>>
>> The goal here is to come up with an identifier for an "OS tarball image" that's acceptable across projects and isn't confusing for people who are creating images.
>>
>
>Seems fine to just have tar be both the container and image format, even
>if it means the metadata portion just turns out to be null. Right? The
>key is to be able to feed it to hypervisors that can deal with it, and
>Ironic is presumably able to deal with it since they're asking for it.

Yeah, this could work as well. It'd be weird to have it been both but I guess
that's fine from a metadata perspective.

An image's container and disk format shouldn't be the same for the same image,
though. Unless I'm missing something.

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160125/21700d1b/attachment.pgp>