creating an image uploads data, and afterwards checks for metadata validity

Bug #1035982 reported by Josh Durgin
38
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Glance
Fix Released
Medium
Alex Meade

Bug Description

For example, if you leave out --container-format, you get:

$ echo 'test' > testfile
$ glance -v image-create --name test --disk-format raw --file testfile
Request returned failure status.
None
HTTPBadRequest (HTTP 400)

From glance-api, you can see the actual error is:

2012-08-12 16:17:21 ERROR glance.api.v1.images [455ceaaf-77c5-405e-aff4-b28fd7257c46 9ffff08acfff465191808d6feca2f1e5 1bb4732231a94cbaa65037307426690c] Failed to update image metadata. Got error: Invalid container format 'None' for image.

However, all data has been uploaded for the image before this error is hit. This is particularly annoying with larger image files, which may take a long time to upload before reporting an error like this.

This occurs with the latest glance and python-glanceclient, 60576a5baedf910af16b26e0eedb4e487d308166 and a214d983c2ae115c5c4965808f2bd5912c71e4c3 respectively.

Jay Pipes (jaypipes)
Changed in glance:
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Jay Pipes (jaypipes)
milestone: none → folsom-3
Revision history for this message
Jay Pipes (jaypipes) wrote :

It looks like recent changes that made it possible to add an image with a size of 0 messed up the early warning system previously in Glance. :(

Revision history for this message
Jay Pipes (jaypipes) wrote :

Also looks like there are tests that weren't being executed that test for this (and fail) because the tests were named _do_test_xxx instead of test_xxx.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to glance (master)

Fix proposed to branch: master
Review: https://review.openstack.org/11258

Changed in glance:
status: Triaged → In Progress
Thierry Carrez (ttx)
Changed in glance:
milestone: folsom-3 → folsom-rc1
Revision history for this message
Brian Waldon (bcwaldon) wrote :

This is actually a duplicate of 981319, but I'll call the other a duplicate of this since there is an active review here already.

Revision history for this message
Alex Meade (alex-meade) wrote :

Just FYI, this bug makes it so the location is never set in this case. So when the image is deleted it is not deleted from the backend store.

Alex Meade (alex-meade)
Changed in glance:
assignee: Jay Pipes (jaypipes) → Alex Meade (alex-meade)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Fix proposed to branch: master
Review: https://review.openstack.org/12465

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to glance (master)

Reviewed: https://review.openstack.org/12465
Committed: http://github.com/openstack/glance/commit/3bfd7bd56c1a8ebc8aff1218c52ac13b66cabb9f
Submitter: Jenkins
Branch: master

commit 3bfd7bd56c1a8ebc8aff1218c52ac13b66cabb9f
Author: Alex Meade <email address hidden>
Date: Wed Sep 5 13:55:46 2012 -0400

    Raise bad request early if image metadata is invalid

    Image data is currently uploaded into the backend store even if it is a bad
    request. This patch add value validation in the deserializer so we don't set bad
    data. It also does a full validation of the image metadata to make sure
    everything that is needed for an image upload is set correctly before the upload
    can occur.

    There were currently some relevant tests that had incorrect names causing them
    to not run. These have been fixed and modified.

    Fixes bug 1035982

    Change-Id: I6f3ef83ba7b3de3cb885fad9737fef1a03d9222c

Changed in glance:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in glance:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in glance:
milestone: folsom-rc1 → 2012.2
Revision history for this message
Jakub Ružička (jruzicka) wrote :

I can still reproduce this with latest glance, but I'm unable to reopen this bug. Should I create a new one?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.