Data loss of properties during normal server snapshot process
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Glance |
Fix Released
|
Critical
|
Jay Pipes |
Bug Description
This is a critical issue.
Identified during testing with Tempest on current devstack. If you create a server and then take a snapshot of that server to create a new image, the properties (metadata in the Compute API) originally given to the image during image "registration" (to get an image ID) are marked deleted when the snapshot image file is actually uploaded.
In Tempest's test_image_metadata test cases, this becomes obvious, and the results are not good.
Basically, the test case does this:
POST /servers/
with {'createImage': {'name': 'image12345', 'metadata': {'key1': 'value1', 'key2': 'value2'}}} as the request body.
The call succeeds and a new image is created. However, the 'key1' and 'key2' metadata keys are conspicuously absent from the output of GET /images/
mysql> select deleted_at, deleted, name, value from image_properties where image_id = 'f411e336-
+------
| deleted_at | deleted | name | value |
+------
| NULL | 1 | backup_type | NULL |
| NULL | 0 | image_location | snapshot |
| NULL | 0 | image_state | available |
| NULL | 1 | image_type | snapshot |
| NULL | 1 | instance_ref | http://
| NULL | 1 | instance_uuid | 60fc2546-
| NULL | 0 | kernel_id | 89ab6edc-
| NULL | 1 | key1 | value1 |
| NULL | 1 | key2 | value2 |
| NULL | 0 | owner_id | admin |
| NULL | 0 | ramdisk_id | NULL |
| NULL | 1 | user_id | admin |
+------
Note a number of things:
a) The deleted_at column is NULL even for the properties that have deleted=1
b) The deleted column is 1 for properties that were "added" to the image on the original call to POST /images
* backup_type, image_type, instance_ref, instance_uuid, user_id, key1, and key2 are all passed to the original call to register a snapshot of server 60fc2546-
* image_location, image_state, kernel_id, ramdisk_id and owner_id are given in the call to PUT /images/
This is all due to the following code in the glance.
orig_status = orig_image_
if image_data is not None and orig_status != 'queued':
raise HTTPConflict(
try:
if image_data is not None:
Note that the call to registry.
The easiest solution is one of the following:
1) Have the client set the X-Glance-
2) If an image file is being uploaded, do not purge existing props
Neither is particularly palatable, but unfortunately we need to deal with this in some non-force-
Changed in glance: | |
status: | Triaged → In Progress |
Changed in nova: | |
status: | New → In Progress |
assignee: | nobody → Brian Waldon (bcwaldon) |
no longer affects: | nova |
Changed in glance: | |
status: | In Progress → Fix Committed |
Changed in glance: | |
status: | Fix Committed → Fix Released |
Changed in glance: | |
milestone: | essex-2 → 2012.1 |
https:/ /review. openstack. org/#change, 2207