Comment 0 for bug 1371728

Revision history for this message
Alexander Tivelkov (ativelkov) wrote :

UpdateImage call in v2 ( PATCH /v2/images/%imageid%) fetches the whole image object from database (, modifies some of its properties with appropriate matching methods (_do_raplace, _do_add etc) and then saves the object in ImageRepo

The imageRepo takes the object, renders it to dictionary ( and then passes this dictionary to db_api.image_update(), which eventually executes UPDATE query and replaces all the fields in database with these values.

This is not transactional, and other operations may interfere between image fetching and update query.

For example, imagine we have an image with name "test" and min_ram "10".
If we concurrently execute two image-update requests:
  'image-update --name test2'
  'image-update --min-ram 100'

A race condition occurs. The result image is undetermined: it may be either {'name': 'test', 'min_ram': 100} or {'name': 'test2', 'min_ram': 10} or {'name': 'test2', 'min_ram': 100'} - depending on which request fetches the object first.
It may be had to reproduce this in normal circumstances, but once the database load becomes higher, it may show up.
To reproduce it for sure one may add a event let.sleep() command after line 119 of glance/api/v2/, to increase the timespan between image fetching and image update.