copy_image_to_volume calls fetch_to_raw for transfer even if the image is raw
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
Undecided
|
Jay Bryant |
Bug Description
We have been running into a problem on PowerPC systems using the storwize_svc driver where they fail to copy an image to volume with the following error:
"cinder create --display-
Traceback is:
['Traceback (most recent call last):\n', '
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
File "/usr/lib/
PowerPC systems don't have qemu-img installed, so the error isn't surprising. For this reason the storwize_svc support is limited to RAW images.
Unfortunately, when storwize_svc calls out to the default iscsi copy_image_
It seems to me that copy_image_
Changed in cinder: | |
status: | New → Invalid |
status: | Invalid → Confirmed |
Changed in cinder: | |
milestone: | none → havana-rc1 |
status: | Fix Committed → Fix Released |
Changed in cinder: | |
milestone: | havana-rc1 → 2013.2 |
Not sure, but I seem to recall having this discussion in the past and I think I actually removed all of the crazy checks that were in place on types. The reason being is that fortunately the qemu convert function is pretty smart, and if the image is already in the correct format it won't go through and change it, it's basically a noop at that point.
I'll give folks a chance to chime in and tell me I'm wrong etc, but I'm thinking this is probably ok as is and probably the right way to go. Perhaps I should add some comments to the effect of what I've stated above?