Nova image list does not list killed images.

Description :

 Upload image of size 25MB to Glance.While adding image to Glance,error message indicates data provided is not complete as Ram and kernel details are not provided.
              But in the list of images ,status of the above image will be 'SAVING' which should be 'ERROR' as the image is not uploaded properly.

Command to reproduce this bug :

root@OpenstackEssex10:~# glance -A 93aa6ecbcaaa4e178a927035160281bf add name="amitest-image" is_public=true < /root/openstackessex/ubuntuimg/ami-tty/image
==================================================================================================================================================[100%] 13.6M/s, ETA 0h 0m 0s
Failed to add image. Got error:
Data supplied was not valid.
Details: 400 Bad Request

The server could not comply with the request since it is either malformed or otherwise incorrect.

 Failed to activate image. Got error: Data supplied was not valid. Details: 400 Bad Request The server could not comply with the request since it is either malformed or otherwise incorrect. Failed to update image metadata. Got error: Data supplied was not valid. Details: Invalid disk format 'None' for image.
Note: Your image metadata may still be in the registry, but the image's status will likely be 'killed'.

Status is retrieved as below :

root@OpenstackEssex10:~# nova image-list

+-----------------------------------------------------------+--------------------------------------+-----------------------------+-------------------------+
| ID | NAME | STATUS |SERVER |
+-----------------------------------------------------------+---------------------------------------+-----------------------------+-------------------------+
| 63afbb9c-9625-425b-82c7-dcd90ba2fd46 | amitest-image | SAVING | |
+-----------------------------------------------------------+---------------------------------------+-----------------------------+-------------------------+

To reproduce the above bug , I considered the following scenario :

1. Upload an image of size 25 MB.

root@OpenstackEssex10:~# glance -A 93aa6ecbcaaa4e178a927035160281bf add name="amitest-image" is_public=true < /root/openstackessex/ubuntuimg/ami-tty/image
==================================================================================================================================================[100%] 13.6M/s, ETA 0h 0m 0s

2. The above command results in an error,

  Failed to add image. Got error:
Data supplied was not valid.
Details: 400 Bad Request

The server could not comply with the request since it is either malformed or otherwise incorrect.

 Failed to activate image. Got error: Data supplied was not valid. Details: 400 Bad Request The server could not comply with the request since it is either malformed or otherwise incorrect. Failed to update image metadata. Got error: Data supplied was not valid. Details: Invalid disk format 'None' for image.
Note: Your image metadata may still be in the registry, but the image's status will likely be 'killed'.

3. The image is Killed in Glance but when I retrieve the list of images using 'nova image-list' the status of the image is SAVING.

4. When glance fails to update the image metadata from SAVING to ACTIVE ,a Rollback is performed on the db transaction.
     As a result the status of the image is SAVING.

5. Along with the Rollback or instead of Rollback ,is there any way to update the image metadata to KILLED using the
     existing method _kill() in glance.

Only images in an active, queued, or saving state are supposed to show up in nova image-list. If you need to administer images, you should use glance directly.

Sailaja:

You need to provide a disk and container format before or during image data upload. There aren't any database transactions happening that are rolled back, as the API is deciding to reject your request early. I also agree it is confusing, but the state map we use within nova to represent glance images is as follows:

           'active': 'ACTIVE',
            'queued': 'SAVING',
            'saving': 'SAVING',
            'deleted': 'DELETED',
            'pending_delete': 'DELETED',
            'killed': 'ERROR'

I'm willing to bet your image is actually 'queued' in glance, but showing as 'SAVING' in nova. The image shouldn't be killed, you just need to perform a valid action on it. It didn't change the state of the image, so you should just be able to try again.

Brian ,

 The following is the glance-registry's log ,which indicates a rollback on a sqlalchemy db call.

   2012-04-12 17:01:39 2470 DEBUG [glance.registry.api.v1.images] Updating image 209dfbfc-c965-4a8f-bb9c-a9a9e02cd3c2 with metadata: {u'status': u'active', u'location': u'file:///opt/stack/glance/images/209dfbfc-c965-4a8f-bb9c-a9a9e02cd3c2'}
2012-04-12 17:01:39 2470 INFO [sqlalchemy.engine.base.Engine.0x...cf10] BEGIN (implicit)
2012-04-12 17:01:39 2470 INFO [sqlalchemy.engine.base.Engine.0x...cf10] SELECT images.created_at AS images_created_at, images.updated_at AS images_updated_at, images.deleted_at AS images_deleted_at, images.deleted AS images_deleted, images.id AS images_id, images.name AS images_name, images.disk_format AS images_disk_format, images.container_format AS images_container_format, images.size AS images_size, images.status AS images_status, images.is_public AS images_is_public, images.location AS images_location, images.checksum AS images_checksum, images.min_disk AS images_min_disk, images.min_ram AS images_min_ram, images.owner AS images_owner, images.protected AS images_protected, image_properties_1.created_at AS image_properties_1_created_at, image_properties_1.updated_at AS image_properties_1_updated_at, image_properties_1.deleted_at AS image_properties_1_deleted_at, image_properties_1.deleted AS image_properties_1_deleted, image_properties_1.id AS image_properties_1_id, image_properties_1.image_id AS image_properties_1_image_id, image_properties_1.name AS image_properties_1_name, image_properties_1.value AS image_properties_1_value, image_members_1.created_at AS image_members_1_created_at, image_members_1.updated_at AS image_members_1_updated_at, image_members_1.deleted_at AS image_members_1_deleted_at, image_members_1.deleted AS image_members_1_deleted, image_members_1.id AS image_members_1_id, image_members_1.image_id AS image_members_1_image_id, image_members_1.member AS image_members_1_member, image_members_1.can_share AS image_members_1_can_share
FROM images LEFT OUTER JOIN image_properties AS image_properties_1 ON images.id = image_properties_1.image_id LEFT OUTER JOIN image_members AS image_members_1 ON images.id = image_members_1.image_id
WHERE images.id = %s AND images.deleted = %s
2012-04-12 17:01:39 2470 INFO [sqlalchemy.engine.base.Engine.0x...cf10] (u'209dfbfc-c965-4a8f-bb9c-a9a9e02cd3c2', 0)
2012-04-12 17:01:39 2470 DEBUG [sqlalchemy.engine.base.Engine.0x...cf10] Col ('images_created_at', 'images_updated_at', 'images_deleted_at', 'images_deleted', 'images_id', 'images_name', 'images_disk_format', 'images_container_format', 'images_size', 'images_status', 'images_is_public', 'images_location', 'images_checksum', 'images_min_disk', 'images_min_ram', 'images_owner', 'images_protected', 'image_properties_1_created_at', 'image_properties_1_updated_at', 'image_properties_1_deleted_at', 'image_properties_1_deleted', 'image_properties_1_id', 'image_properties_1_image_id', 'image_properties_1_name', 'image_properties_1_value', 'image_members_1_created_at', 'image_members_1_updated_at', 'image_members_1_deleted_at', 'image_members_1_deleted', 'image_members_1_id', 'image_members_1_image_id...

Looks like you're not working on that anymore. Please set back to InProgress and reassign to you if you're working on proposing a change for merging.

Based on the comments it sounds like Brian indicated that the original report was not considered a bug. If that is not the case, please feel free to reopen.