[openstack-dev] [glance][ironic][cinder][nova] 'tar' as an image disk_format

Clint Byrum clint at fewbar.com
Sat Jan 23 17:08:45 UTC 2016

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.

More information about the OpenStack-dev mailing list