Split image's size into 2 separate attributes

Registered by Flavio Percoco

Currently, Glance's image have a size attribute which is being misunderstood and overloaded.

Image's size can refer to either the file size or the actual image size, which in cases like qcow2 may not be the same. This blueprint proposes splitting current size attribute in 2 separate attributes: image_size and file_size. The former refers at the real size of the image and the later at the actual size of the uploaded file. In most of the cases both fields will hold the same value, however, the number of cases where they may differ is as well big.

This blueprint considers both fields important for an image but not exactly required for it to exist. The image_size will allow users to know what is the actual size of the image and how much space the need to reserve in order to use it - cinder blocks allocation, for example. The file_size instead is necessary to support quotas, CLI progress bars, rate-limits, meetering and others.

It is possible to argue the need of this blueprint by saying that the actual image size could be part of the image properties / metadata. However, it is important to remember that image_size is a first citizen attribute in most of the external tools. Also, an attribute will ease the consumption of its value from Nova, Cinder and other tools relying on it.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Medium
Drafter:
Flavio Percoco
Direction:
Approved
Assignee:
Flavio Percoco
Definition:
Approved
Series goal:
Accepted for icehouse
Implementation:
Implemented
Milestone target:
milestone icon 2014.1
Started by
Mark Washenberger
Completed by
Flavio Percoco

Related branches

Sprints

Whiteboard

Instead of creating 2 new size attributes, I think we should keep the old size attributed and add a new virtual_size attribute. This will make the migration simpler from a code and UX point of view.
-- flaper87

I really like the idea of fixing the confusion here. I have a few concerns however.
1) size is already being used mostly as "file size", so it seems like this would create backwards compatibility problems. Maybe you are hoping to address this concern with the "virtual size" proposal in the comment above?
2) Technically an image in certain formats can present multiple block devices (at least I am familiar with a given image representing both a base and swap). So the size of the block device may not apply for all images, perhaps?
3) File size might actually be able to vary based on the location, if we take the view that the size and checksum at the top level of the image dictionary refer to the unpacked raw format of a block device. So should we move a property down into the location dictionaries?
Thanks!
--markwash

1) Correct, In order to avoid backwards incompatibility, I think just adding a new field is the right thing to do.
2) mmh, not sure TBH. Could you please elaborate more?
3) I think the size should represent what users get when they download the image from glance. I don't think it should be moved down to the locations dictionary. The file size is 1.
-- flaper87

Approved based on the idea of adding the optional 'virtual-size' parameter to the top level image dictionary. Now we just need to figure out how to add in virtual-checksum for same :-)
-- markwash

Gerrit topic: https://review.openstack.org/#q,topic:split-image-size,n,z

Addressed by: https://review.openstack.org/65499
    Add a virtual_size attribute to the Image model

Gerrit topic: https://review.openstack.org/#q,topic:bp/split-image-size,n,z

<markwash> bumping to I-3 but let's still do this and soon! ping me if I fail to review it </markwash>

Addressed by: https://review.openstack.org/72650
    Add `virtual_size` to Glance's API v2

Addressed by: https://review.openstack.org/73339
    Make 'virtual_size' read-only for v1
(ABANDONED, as virtual_size access is effectively disallowed via absence in the IMAGE_META_HEADERS whitelist) -- vui

Looks like this is done, is that correct?
-- markwash

Yes, just moved it to Implemented
-- flaper87

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.