Open Stack

Hi Duncan,

On Sat, Jan 23, 2016 at 2:00 PM, Duncan Thomas <duncan.thomas at gmail.com> wrote:
> 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.
>

As far as i know the ironic only supports creating gpt partitions in UEFI mode.
GPT  partitions are needed if the disk size is more than 2 TB. The whole disk
image generated by DIB only supports MSDOS disk labels. However with tar
payload we are supporting both MSDOS and GPT disk labels. GPT is a must in
a data center environment that bios boot's the server and have >2TB HDD's.
This is one use case i think of. Please correct me if i am wrong here.

Tar based OS images are simple, They are created by installing packages in a
chroot and compressing them as tar. This is simpler than building disk images
where file systems and loop devices have to be created.

Tar based images are faster to transfer over the network than whole disk images.

Tar based OS images are getting popular, especially redhat installers
like anaconda are
already supporting them.


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

I understand that this creates more headaches in cinder.

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

The feature is called 'tar-payload'  converting to any other format
doesn't make sense.
Do you have a suggestion as to what format we should consider
converting to instead of
adding a disk_format named tar?

-- 
Arun S A G
http://zer0c00l.in/