[
https://issues.apache.org/jira/browse/CLOUDSTACK-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13753521#comment-13753521
]
Nitin Mehta commented on CLOUDSTACK-4534:
-----------------------------------------
Edison / Min - We just remove the DB entries as part of the scavenger thread -
why ? We should clean the DB entries as part of the API itself.
Also in the scavenger thread if there are some DB entries left over we should
delete them physically and not just the db entries - scavenger thread ensures
sanity in case cleanup failed for some reason. Is there a reason why we dont do
that anymore?
Sanjeev - I see that deleteVolumeCmd didn't issue any HV delete command for
vmware ? Is that correct ?
> [object_store_refactor] Deleting uploaded volume is not deleting the volume
> from backend
> ----------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-4534
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4534
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller, Volumes
> Affects Versions: 4.2.1
> Environment: git rev-parse HEAD~5
> 1f46bc3fb09aead2cf1744d358fea7adba7df6e1
> Cluster: VMWare
> Storage: NFS
> Reporter: Sanjeev N
> Fix For: 4.2.1
>
> Attachments: cloud.dmp, management-server.rar
>
>
> Deleting uploaded volume is not deleting the volume from backend and not
> marking removed field in volumes table.
> Steps to Reproduce:
> ================
> 1.Bring up CS with vmware cluster using NFS for both primary and secondary
> storage
> 2.Upload one volume using uploadVolume API
> 3.When the volume is in "Uploaded" state try to delete the volume
> Result:
> ======
> from volume_store_ref volume entry got deleted but volume was not deleted
> from secondary storage and removed filed was not set in volumes table.
> Observations:
> ===========
> Log snippet from management server log file as follows:
> 2013-08-28 03:18:08,269 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null)
> ===START=== 10.146.0.131 -- GET
> command=deleteVolume&id=e9ee6c0d-d149-4771-a494-6efda849b2ce&response=json&sessionkey=vNQ7kc2GdEuxzKje8MQ2xSAqbAQ%3D&_=1377674288184
> 2013-08-28 03:18:08,414 DEBUG [cloud.user.AccountManagerImpl]
> (catalina-exec-20:null) Access granted to Acct[2-admin] to Domain:1/ by
> AffinityGroupAccessChecker_EnhancerByCloudStack_86df51a8
> 2013-08-28 03:18:08,421 INFO [cloud.resourcelimit.ResourceLimitManagerImpl]
> (catalina-exec-20:null) Discrepency in the resource count (original
> count=77179526656 correct count = 78867689472) for type secondary_storage for
> account ID 2 is fixed during resource count recalculation.
> 2013-08-28 03:18:08,446 DEBUG [cloud.api.ApiServlet] (catalina-exec-20:null)
> ===END=== 10.146.0.131 -- GET
> command=deleteVolume&id=e9ee6c0d-d149-4771-a494-6efda849b2ce&response=json&sessionkey=vNQ7kc2GdEuxzKje8MQ2xSAqbAQ%3D&_=1377674288184
> 2013-08-28 03:18:32,766 DEBUG [cloud.storage.StorageManagerImpl]
> (StorageManager-Scavenger-1:null) Storage pool garbage collector found 0
> templates to clean up in storage pool: pri_esx_306
> 2013-08-28 03:18:32,772 DEBUG [cloud.storage.StorageManagerImpl]
> (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 0
> templates to cleanup on template_store_ref for store:
> 37f6be5b-0899-48b4-9fd8-1fe483f47c0e
> 2013-08-28 03:18:32,774 DEBUG [cloud.storage.StorageManagerImpl]
> (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 0
> snapshots to cleanup on snapshot_store_ref for store:
> 37f6be5b-0899-48b4-9fd8-1fe483f47c0e
> 2013-08-28 03:18:32,776 DEBUG [cloud.storage.StorageManagerImpl]
> (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 1
> volumes to cleanup on volume_store_ref for store:
> 37f6be5b-0899-48b4-9fd8-1fe483f47c0e
> 2013-08-28 03:18:32,777 DEBUG [cloud.storage.StorageManagerImpl]
> (StorageManager-Scavenger-1:null) Deleting volume store DB entry:
> VolumeDataStore[2-20-2volumes/2/20/7e5778fd-c4bf-35b3-9e7a-9ab8500ab469.ova]
> Volume in the backend:
> [root@Rhel63-Sanjeev 20]# pwd
> /tmp/nfs/sec_306/volumes/2/20
> [root@Rhel63-Sanjeev 20]# ls -l
> total 898008
> -rwxrwxrwx+ 1 root root 459320832 Aug 27 13:57
> 7e5778fd-c4bf-35b3-9e7a-9ab8500ab469.ova
> -rwxrwxrwx+ 1 root root 459312128 Sep 17 2010 CentOS5.3-x86_64-disk1.vmdk
> -rwxrwxrwx+ 1 root root 147 Sep 17 2010 CentOS5.3-x86_64.mf
> -rwxrwxrwx+ 1 root root 5340 Sep 17 2010 CentOS5.3-x86_64.ovf
> -rwxrwxrwx+ 1 root root 340 Aug 27 13:58 volume.properties
> [root@Rhel63-Sanjeev 20]#
> Attaching management server log file and cloud db.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
