> 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 > > Rohit Yadav wrote: > 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>
Just checked, fix is already in 4.3 by Edison. Thanks. - 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 > >
