Description of problem: now that uploadVolume has been removed, downloadImage must be used in its place. Actually for downloading an image from a local path it should be used method http with URL using file:// protocol. It would be better having a method local requiring a file path instead.
Technically it's not hard to implement, we could support something like: downloadImage({'method': 'local', 'path': '...'}, spUUID, sdUUID, imgUUID) (probably based on dd)
raising severity since http + file:// seems not working (bug #1037584)
Re - targeting to 3.3.0 and proposing this as blocker, since it's blocking another bug, targeted to 3.3.0 and already acked as blocker.
(In reply to Sandro Bonazzola from comment #3) > Re - targeting to 3.3.0 and proposing this as blocker, since it's blocking > another bug, targeted to 3.3.0 and already acked as blocker. According to bug 1034777 comment 6 there's no need for this in 3.3.0. You can use uploadVolume, provided that the client connection doesn't timeout.
This should be covered as part of the work for storing OVFs on any domain.
how comes this is for 3.4, if it blocks https://bugzilla.redhat.com/show_bug.cgi?id=1034777 which is targeted for 3.3?
(In reply to movciari from comment #7) > how comes this is for 3.4, if it blocks > https://bugzilla.redhat.com/show_bug.cgi?id=1034777 which is targeted for > 3.3? As you can see Bug 1034777 is ON_QA so clearly it is not blocked by this bug.
Hi, Liron, I can't access referenced patch 23197. Where may I find the changes for using downloadImage verb for file:// protocol ?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-0504.html