Details
-
Bug
-
Status: Open
-
Critical
-
Resolution: Unresolved
-
4.4.1
-
None
-
None
-
Security Level: Public (Anyone can view this level - this is the default.)
-
None
Description
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)
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.