> On Nov. 20, 2014, 6:33 p.m., edison su wrote:
> > seems it's already checked into master and 4.5 by Nitin? see commit:
> > 5393387bbd4e2d3659fb0c7171e6ff347ad6a07b
>
> David Bierce wrote:
> This was a backport to 4.2 and 4.3
David, the applies cleanly on 4.2 so I've merged it but it fails on 4.3. Also,
it would be great if you can consider sending Github PR :)
Can you create a new patch for 4.3?
This is from 4.2:
commit 7edde4a5c7d849f5c9184972f8d4bc1f79770f65
Author: David Bierce <david.bie...@appcore.com>
Date: Wed Aug 27 09:31:18 2014 -0500
PATCH: CLOUDSTACK-6254
Fixes the cleanup process to only remove the Template symlink, instead of
delete the template from Secondary Storage.
Signed-off-by: Rohit Yadav <rohit.ya...@shapeblue.com>
- Rohit
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/24779/#review62374
-----------------------------------------------------------
On Aug. 27, 2014, 3:46 p.m., David Bierce wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/24779/
> -----------------------------------------------------------
>
> (Updated Aug. 27, 2014, 3:46 p.m.)
>
>
> Review request for cloudstack.
>
>
> Bugs: CLOUDSTACK-6254
> https://issues.apache.org/jira/browse/CLOUDSTACK-6254
>
>
> Repository: cloudstack-git
>
>
> Description
> -------
>
> PATCH] This is a quick stab at fixing a dataloss bug. The ultimate
> solution is to refactor UploadManager to not use any deprecated code. It
> appears there is still code left over that uses the UploadVO/Dao which no
> long contains data about URL transfers. This method was hardcoded to always
> pass Upload.Type.VOLUME as part of cleanup which was causing templates to be
> removed entirely from secondary storage not just the symlink on secondary
> storage.
>
> Rather than try to refactor all of it out, this puts
> logic for determining if the cleanup task is for a volume or a template
> by doing a lookup on the URL. It is a duplication of the same logic
> from the calling method but is a very minimal code change until the
> large problem is fixed.
>
>
> Diffs
> -----
>
>
> engine/api/src/org/apache/cloudstack/storage/image/datastore/ImageStoreEntity.java
> 7ebfd0d
>
> engine/storage/image/src/org/apache/cloudstack/storage/image/store/ImageStoreImpl.java
> 7bbe324
>
> engine/storage/src/org/apache/cloudstack/storage/image/BaseImageStoreDriverImpl.java
> 2905f08
>
> engine/storage/src/org/apache/cloudstack/storage/image/ImageStoreDriver.java
> 444a6c7
>
> plugins/storage/image/default/src/org/apache/cloudstack/storage/datastore/driver/CloudStackImageStoreDriverImpl.java
> 4796653
> server/src/com/cloud/storage/StorageManagerImpl.java 2a79b0c
>
> Diff: https://reviews.apache.org/r/24779/diff/
>
>
> Testing
> -------
>
> On Cloudstack 4.2 4.3
> Set cleanupurl to 30 seconds. Downloaded a template, cleanup remvoed it from
> database, didn't remove the template.
> Downloaded Volume, volume was cleaned up from secondary stoage and database.
>
>
> Thanks,
>
> David Bierce
>
>
