Open Stack

I guess my wisdom would be 'why'? What does this enable you to do that you
couldn't do with similar ease with the formats we have and are people
trying to do that frequently.

We've seen in cinder that image formats have a definite security surface to
them, and with glance adding arbitrary conversion pipelines, that surface
is going to increase with every format we add. This should mean we tend
towards being increasingly conservative I think.

We've heard a possible feature, but zero use case that I can see. Why is
this better than converting your days to a supported format?
On 23 Jan 2016 16:57, "Brian Rosmaita" <brian.rosmaita at rackspace.com> wrote:

> 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.
>
> Thanks in advance for your feedback,
> brian
>
> [0] https://bugs.launchpad.net/glance/+bug/1535900
> [1] https://github.com/openstack/glance/blob/master/doc/source/formats.rst
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160124/a6aa66bd/attachment.html>