We found that glance's DB state may remain inconsistent/confusing without proper periodic checking, in case faults occur.
Below are two examples:
1. When "glance image-create" is issued with "copy-from=http://..." option, the image state transits from "queued" to "saving," before the image is copied from http backend to the glance host. If the exeuction is interrupted at this time, then the image will stay in "saving" state.
While in such case, glance does return an error code to the external user who issued the command, we believe that keeping the image in the "saving" state may confuse other external users. It would be better to differentiate a failed image uploading with the case where an image is being uploaded. A periodic check may help in this case. Alternatively, one can trigger the state transition at the time when the image upload is believed to have failed.
2. If the execution related to a "glance image-delete" request is interrupted, then it is possible that the "status" in DB table "glance.images" has transited to "deleted" but the "deleted" field remains to be False. Since this case clearly indicates the occurance of an error, we think it may be better to periodically check the existence of such inconsistent states, transit "deleted" to True accordingly, and mark the occurance of error probably in a dedicated error DB table.
Is this a dup of https:/