Bug 1021525 - [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'
[vdsm] [external-provider] uploadImage is failing with an uninformative error...
Status: CLOSED WONTFIX
Product: vdsm
Classification: oVirt
Component: General (Show other bugs)
---
x86_64 Unspecified
unspecified Severity medium (vote)
: ovirt-4.0.0-alpha
: ---
Assigned To: Idan Shaby
Aharon Canan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-21 09:03 EDT by Elad
Modified: 2016-03-10 05:09 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-10 05:09:38 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑4.0.0?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)
logs (146.96 KB, application/x-gzip)
2013-10-21 09:03 EDT, Elad
no flags Details

  None (edit)
Description Elad 2013-10-21 09:03:05 EDT
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 07:51:43 EDT
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 12:20:41 EDT
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 04:59:16 EDT
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 08:46:00 EDT
Bug for 3.6
Comment 13 Red Hat Bugzilla Rules Engine 2015-10-19 06:58:53 EDT
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 08:30:29 EDT
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

Note You need to log in before you can comment on or make changes to this bug.