glance image-create creates image of size zero instead of failing

[Chris Friesen]

I accidently tried creating a new image using

glance image-create --name cirros --is-public true --container-format bare --disk-format qcow2 --location https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img

with an HTTP URL from a virtual machine with no external network connectivity. To my surprise, the command appeared to pass and the status showed as "active". However, the image size was zero and of course the image was non-bootable.

This is unexpected. If glance can't download the specified URL then the command should fail noisily to minimize confusion. Certainly the status shouldn't ever be "active" for a zero-size image.

[Feilong Wang (flwang)]

Hi Chris, are you sure the image is in "active" state? Since based on current implement, it should be in "queued" state. And I can't recreate it in my dev env.

Besides, I would say it's a dup of https://bugs.launchpad.net/python-glanceclient/+bug/1184965

[Chris Friesen (cbf123)]

This is not a dupe of 1184965, I'm specifying all the rest of the options. (I just realized I should have been more clear above.)

The full command that I'm running is:

glance image-create --name cirros --is-public true --container-format bare --disk-format qcow2 --location https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img

I'm using a standard Ubuntu 12.04 image with grizzly from http://ubuntu-cloud.archive.canonical.com. On this system eth0 is my connection to the outside world, while eth1 is a private network between the control/compute nodes. If I "down" eth0 and then run the above command, it sits for a while and then spits out the following:

+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | None |
| container_format | bare |
| created_at | 2013-09-17T14:57:01.543482 |
| deleted | False |
| deleted_at | None |
| disk_format | qcow2 |
| id | 31b873a6-a56a-48d2-9932-ad2584ff13a7 |
| is_public | True |
| min_disk | 0 |
| min_ram | 0 |
| name | cirros |
| owner | None |
| protected | False |
| size | 0 |
| status | active |
| updated_at | 2013-09-17T14:57:01.597705 |
+------------------+----

At this point, running "glance image-list" gives:

+--------------------------------------+--------------+-------------+------------------+-----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+--------------------------------------+--------------+-------------+------------------+-----------+--------+
| 2384c6db-5454-40b7-876c-fd7c90057bdb | fedora64 | qcow2 | bare | 237371392 | active |
| d32274eb-8b1f-42bb-8a3c-8e462c911553 | myFirstImage | qcow2 | bare | 9761280 | active |
| 31b873a6-a56a-48d2-9932-ad2584ff13a7 | cirros | qcow2 | bare | | active |
+--------------------------------------+--------------+-------------+------------------+-----------+--------+

[Iccha Sethi (iccha-sethi)]

With which version of glance did u face this issue?

[Chris Friesen (cbf123)]

On 10/07/2013 03:52 PM, Iccha Sethi wrote:
> With which version of glance did u face this issue?

This was in grizzly, on Ubuntu 12.04.

Chris

[Chris Friesen (cbf123)]

On 10/07/2013 03:52 PM, Iccha Sethi wrote:
> With which version of glance did u face this issue?

I just verified that I could recreate the problem with
python-glanceclient, version 0.9.0-0ubuntu1.1~cloud0 and python-nova
version 2013.1.2-0ubuntu1~cloud0

Chris

[Zhi Yan Liu (lzy-dev)]

Current our most store driver's 'get_size()' method does not raise exception when it meet exception but return '0' directly, for http driver https://github.com/openstack/glance/blob/master/glance/store/http.py#L151 , so for store's upper layer such as https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L469 will active image with zero size since 'location' is provided.

There is a workaround under current design, you can tell glance image's size when you create it like following, but you will also meet exception when you consuming it such as trigger provisioning since http store can not receive remote image with a unusable network link.

glance image-create --name cirros --is-public true --container-format bare --disk-format qcow2 --location https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img --size 123456

I'm not sure this is a defect but from end user's perspective this behavior is strange, so probably we need import an exception mechanism (and related up layer handling) for store 'get_size()'. any thoughts?

[Chris Friesen (cbf123)]

On 10/07/2013 08:29 PM, Zhi Yan Liu wrote:

> There is a workaround under current design, you can tell glance image's
> size when you create it like following, but you will also meet exception
> when you consuming it such as trigger provisioning since http store can
> not receive remote image with a unusable network link.
>
> glance image-create --name cirros --is-public true --container-format
> bare --disk-format qcow2 --location
> https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img
> --size 123456

Between --size and --checksum, I suppose that's sufficient to validate
an image.

> I'm not sure this is a defect but from end user's perspective this
> behavior is strange, so probably we need import an exception mechanism
> (and related up layer handling) for store 'get_size()'. any thoughts?

I think that if we can't talk to the server, or if the returned image
file is blatantly undersized (smaller than the smallest possible disk
image file) then we should log the problem (if we don't already) and the
image should show a "status" of "ERROR".

The fact that the image shows a status of "active" when it has a size of
zero is really misleading.

Chris

[Jon Bernard (jbernard)]

This is related to bug https://bugs.launchpad.net/glance/+bug/1257273
Also, it may be fixed by https://review.openstack.org/#/c/62031/

[Erno Kuvaja (jokke)]

I agree with Jon, looks like this was fixed. Can we get this closed as well?

[Brian Rosmaita (brian-rosmaita)]

Agree that this was fixed by fix for https://bugs.launchpad.net/glance/+bug/1257273 , which has been released.