Bug 1021525

Summary: [vdsm] [external-provider] uploadImage is failing with an uninformative error on vdsm.log: 'curl: (22) The requested URL returned error: 413 Request Entity Too Large'
Product: [oVirt] vdsm Reporter: Elad <ebenahar>
Component: GeneralAssignee: Idan Shaby <ishaby>
Status: CLOSED WONTFIX QA Contact: Aharon Canan <acanan>
Severity: medium Docs Contact:
Priority: unspecified    
Version: ---CC: amureini, bazulay, bugs, ebenahar, fsimonce, gklein, ishaby, lpeer, mgoldboi, rbalakri, scohen, tnisan, yeylon, ylavi
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-10 10:09:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

Description Elad 2013-10-21 13:03:05 UTC 
Created attachment 814596 [details]
logs

Description of problem:
vdsm fails in uploadImage in case the exported disk is larger than 1GB

Version-Release number of selected component (if applicable):
vdsm-4.13.0-0.3.beta1.el6ev.x86_64

How reproducible:
100%

Steps to Reproduce:
1. add a glance images external provider to RHEVM
2. create a 3GB disk on RHEVM
3. export the disk to glance domain

Actual results:
vdsm fails to perform uploadImage with this error:

668dc993-22e4-4941-8c93-6ec245e41ac1::ERROR::2013-10-21 15:55:49,014::task::850::TaskManager.Task::(_setError) Task=`668dc993-22e4-4941-8c93-6ec245e41ac1`::Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/task.py", line 857, in _run
    return fn(*args, **kargs)
  File "/usr/share/vdsm/storage/task.py", line 318, in run
    return self.cmd(*self.argslist, **self.argsdict)
  File "/usr/share/vdsm/storage/securable.py", line 68, in wrapper
    return f(self, *args, **kwargs)
  File "/usr/share/vdsm/storage/sp.py", line 1780, in uploadImage
    .upload(methodArgs, sdUUID, imgUUID, volUUID)
  File "/usr/share/vdsm/storage/image.py", line 1162, in upload
    imageSharing.upload(vol.getVolumePath(), methodArgs)
  File "/usr/share/vdsm/storage/imageSharing.py", line 88, in upload
    uploadImageImpl(srcImgPath, methodArgs)
  File "/usr/share/vdsm/storage/imageSharing.py", line 56, in httpUploadImage
    methodArgs.get("headers", {}))
  File "/usr/share/vdsm/storage/curlImgWrap.py", line 81, in upload
    raise CurlError(rc, out, err)
CurlError: ecode=1, stdout=[], stderr=["fork_exec('/bin/dd', 'dd', 'bs=2M', 'if=/rhev/data-center/aa869c3b-e114-4f1d-8e36-1e42f1c7feeb/fe32df15-ca21-4a4d-aa0e-2205c77a414f/images/316feda8-f586-4d04-8b32-b3c55cc924
ea/adb20041-43a4-4b58-a7e4-f484cffe0d03')", "fork_exec('/usr/bin/curl', 'curl', '-q', '--silent', '--fail', '--show-error', '-H', 'Content-Type: application/octet-stream', '-H', 'X-Auth-Token: 9b8c9232d9fc4271b5e0
1c3133b744c7', '--upload-file', '-', 'http://10.35.161.239:9292/v1/images/09ba4280-3e9e-4374-86c2-3a9e319f310b')", 'curl: (22) The requested URL returned error: 413 Request Entity Too Large', "dd: writing `standar
d output': Broken pipe", '123+0 records in', '122+0 records out', '257585152 bytes (258 MB) copied, 10.6424 s, 24.2 MB/s'], message=None
668dc993-22e4-4941-8c93-6ec245e41ac1::DEBUG::2013-10-21 15:55:49,015::task::869::TaskManager.Task::(_run) Task=`668dc993-22e4-4941-8c93-6ec245e41ac1`::Task._run: 668dc993-22e4-4941-8c93-6ec245e41ac1 () {} failed -
 stopping task


Additional info: logs
Comment 7 Elad 2013-10-23 11:51:43 UTC 
Seems to happen when there is not enough space left on glance server's storage devices.
RHEVM does not provide any knowledge of how much space is left on the glance domain, and also, the mentioned error on vdsm (413 code http error) is not informative, there is no way user can realize that his problem is not enough space on the domain.
Comment 10 Allon Mureinik 2014-08-27 16:20:41 UTC 
This is obviously a bug, and should be addressed, but the bottom line is that the operation will fail anyway - only question is how fast it will fail, and how userfriendly the fail is. 
Postponing to 3.5.1
Comment 11 Sandro Bonazzola 2015-09-04 08:59:16 UTC 
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.
Comment 12 Aharon Canan 2015-09-08 12:46:00 UTC 
Bug for 3.6
Comment 13 Red Hat Bugzilla Rules Engine 2015-10-19 10:58:53 UTC 
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 14 Sandro Bonazzola 2015-10-26 12:30:29 UTC 
this is an automated message. oVirt 3.6.0 RC3 has been released and GA is targeted to next week, Nov 4th 2015.
Please review this bug and if not a blocker, please postpone to a later release.
All bugs not postponed on GA release will be automatically re-targeted to

- 3.6.1 if severity >= high
- 4.0 if severity < high