cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-8640) Uploads to S3 Secondary Storage fail, stay at 0% completed
Date Mon, 03 Aug 2015 18:29:05 GMT


ASF subversion and git services commented on CLOUDSTACK-8640:

Commit 60633301ac97d5d5fb66369be35bc85c943aee27 in cloudstack's branch refs/heads/master from
[;h=6063330 ]

Merge pull request #647 from @wido

CLOUDSTACK-8640: Revert to AWS SDK 1.3.22

* pr/647:
  CLOUDSTACK-8640: Revert to AWS SDK 1.3.22

Signed-off-by: Remi Bergsma <>

> Uploads to S3 Secondary Storage fail, stay at 0% completed
> ----------------------------------------------------------
>                 Key: CLOUDSTACK-8640
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: SystemVM
>    Affects Versions: Future, 4.5.1
>         Environment: Ceph RADOS Gateway with Civetweb as Secondary Storage
>            Reporter: Wido den Hollander
>            Assignee: Wido den Hollander
>              Labels: amazon, ceph, rados, s3, secondary_storage
>             Fix For: 4.6.0
> I noticed this after upgrading to 4.5.2 (build from 4.5 branch).
> Uploads never completed when a template was downloaded en directly uploaded to S3 secondary
storage provided by Ceph's RADOS Gateway using Multipart.
> After searching for hours I found this:
> The ProgressEvent of the returned that 0 bytes had been transferred. But when using the
getBytes() method it actually works.
> The upload succeeds, but we check if the amount of uploaded bytes is equal or more then
what we expected. If not, we say the upload failed.
> This happens inside S3TemplateDownloader (which really needs some fixes btw....)
> Tracing this down if it's related to Ceph or actually something in S3TemplateDownloader.
> I also tried the Amazon SDK 1.9.34, but that didn't make a difference.

This message was sent by Atlassian JIRA

View raw message