[
https://issues.apache.org/jira/browse/CLOUDSTACK-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14227502#comment-14227502
]
Hiroki Ohashi commented on CLOUDSTACK-7412:
-------------------------------------------
{noformat}
[Abstract]
Root cause of this issue is a way to handle cache using S3 as
Secondary Storage.
When CloudStack uploads a disk image on Primary Storage(PS) to
Secondary Storage(SS), it caches the disk image on Secondary Staging
Store(SSS). This is a bug.
CloudStack uses disk image cache every time if the cache exists. For
this behavior, the old cache on SSS will be uploaded as a template
though a CloudStack user creates the template from a newer disk image
on PS than the cache.
So, we fixed this issue in a way that CloudStack deletes the cache on
SSS after CloudStack uploads disk image to SS.
[Details]
Process of handling cache is different between copy from SS to
PS(download) and copy from PS to SS(upload).
* Downloading a disk image from SS to PS
This is the case that a CloudStack user creates an instance from a
template. CloudStack caches the image on SSS.
* Uploading a disk image from PS to SS
This is the case that a CloudStack user creates a template from a disk
image of an instance. CloudStack shouldn't cache a disk image because
it usually happens that a cache image is older than a volume of an
instance.
However, there is a bug in branch condition about post process of
uploading a disk image. Then CloudStack doesn't delete the disk image
on SSS.
CloudStack uses a common method to copy a disk image between PS and SS
for upload and download. The method includes post process of disk
image cache.
As a part of post process, it is judged whether a disk image on SSS is
used as cache or not in this method:
a. Delete a disk image as upload procedure
b. Delete a disk image to handle errors
c. Cache a disk image as download procedure
In case of uploading a disk image, branch-a should be selected. But
branch-c is always selected by the condition bug. As a result, a disk
image is left on SSS and used as cache next time a CloudStack user
creates a template from an instance.
{noformat}
> Can't create proper template from VM on S3 secondary storage environment
> ------------------------------------------------------------------------
>
> Key: CLOUDSTACK-7412
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7412
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Template
> Affects Versions: Future, 4.2.1, 4.3.0, 4.4.0, 4.5.0
> Environment: CloudStack 4.3.0 on CentOS 6.5.
> KVM Hypervisor.
> using S3 provider as socondary storage. The storage system is using RADOS.
> using local storage as primary storage.
> Reporter: Akihiko Ota
> Fix For: Future, 4.5.0, 4.6.0, 4.4.3, 4.3.2
>
>
> When I create more than one templates from an existing virtual machine, the
> second and the subsequent template is created the same as first one.
> It doesn't occur in the case of using NFS secondary storage. So I guess this
> is the S3 provider specific issue.
> This could reproduce as following procedure.
> (1) create a virtual machine (name "foo" tentatively), and modify some files
> on ROOT volume of "foo".
> (2) stop "foo". and create template "template-foo.1" from ROOT volume of
> "foo".
> (3) reboot (not re-create) "foo", and modify some files on ROOT volume again.
> (4) stop "foo". and create template "template-foo.2" from ROOT volume of
> "foo".
> I expect that template-foo.2 keeps (3)'s changes. But template-foo.2 is the
> same as template-foo.1. (3)'s changes are not recorded.
> As of (4), CloudStack outputs the following DEBUG message to
> cloudstack-management.log.
> 2014-08-07 19:23:20,094 DEBUG [o.a.c.s.c.m.StorageCacheManagerImpl]
> (Job-Executor-58:ctx-b00fbe22 ctx-6339bae6) there is already one in the cache
> store
> When creating templates on NFS secondary storage environment, this message is
> not output.
> This issue also exists on CloudStack 4.2.1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
