cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Tutkowski (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-7406) Templates using Swift provider reports physical size, and not the virtual size in the template list
Date Thu, 18 Sep 2014 02:17:34 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Tutkowski updated CLOUDSTACK-7406:
---------------------------------------
    Assignee: punith

> Templates using Swift provider reports physical size, and not the virtual size in the
template list
> ---------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-7406
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7406
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>    Affects Versions: 4.4.1
>            Reporter: Francois Gaudreault
>            Assignee: punith
>            Priority: Critical
>
> Looks like the post-download tasks for normal NFS vs. S3/Swift are not the same. Might
have some good reasons (if any?), but a side effect of this is the virtualSize is not properly
reported to CloudStack, which leads to other problems (e.g SolidFire storage plugin creating
LUNs with the wrong size)
> Code snippet of 
> services/secondary-storage/server/src/org/apache/cloudstack/storage/template/DownloadManagerImpl.java
> case DOWNLOAD_FINISHED:
>             if (!(td instanceof S3TemplateDownloader)) {
>                 // we currently only create template.properties for NFS by
>                 // running some post download script
>                 td.setDownloadError("Download success, starting install ");
>                 String result = postDownload(jobId);
>                 if (result != null) {
>                     s_logger.error("Failed post download script: " + result);
>                     td.setStatus(Status.UNRECOVERABLE_ERROR);
>                     td.setDownloadError("Failed post download script: " + result);
>                 } else {
>                     td.setStatus(Status.POST_DOWNLOAD_FINISHED);
>                     td.setDownloadError("Install completed successfully at " + new SimpleDateFormat().format(new
Date()));
>                 }
>             } else {
>                 // for s3 and swift, we skip post download step and just set
>                 // status to trigger callback.
>                 td.setStatus(Status.POST_DOWNLOAD_FINISHED);
>                 // set template size for S3
>                 S3TemplateDownloader std = (S3TemplateDownloader)td;
>                 long size = std.totalBytes;
>                 DownloadJob dnld = jobs.get(jobId);
>                 dnld.setTemplatesize(size);
>                 dnld.setTemplatePhysicalSize(size);
>                 dnld.setTmpltPath(std.getDownloadLocalPath()); // update template path
to include file name.
>             }
> So as you can see, the code simply used the downloaded bytes, not the actual virtual
drive size within the vhd.
> If we could do a PostDownload sub with the proper steps (e.g get file extension, and
grab the virtualSize) I think it would be sufficient.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message