create volume reschedule on image download failure
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
High
|
John Griffith |
Bug Description
The copy_image_
This results in the *unknown* exception being inspected in the task_flow sequence and it doesn't match the list of non-reschedule errors, so it tries again, which is no bueno because the volume already exists and we end up creating another one. The result is 3 volumes are created on the back-end instead of the single one that we requested.
I haven't figured out what is or isn't being downloaded to the new volumes yet and if they fail and its just missed.
The easy fix right now is to wrap the unlink in a try block and pass if DNE.
Longer term, the strategy of retrying on everything NOT in the list may prove to be the wrong strategy? Perhaps we should think about changing the flows to retry ONLY on the identified list of exceptions rather than the other way around to deal with unforseen errors.
Changed in cinder: | |
status: | Fix Committed → Fix Released |
Changed in cinder: | |
milestone: | havana-3 → 2013.2 |
Fix proposed to branch: master /review. openstack. org/42045
Review: https:/