[ https://issues.apache.org/jira/browse/CLOUDSTACK-4534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanjeev N reopened CLOUDSTACK-4534: ----------------------------------- Hi Min, The fix is not working as you mentioned in the comment. Uploaded volume is getting deleted from DB and from back-end only when storage gc is kicked in. However should be deleted as and when the deleteVolume API is fired. Following is the snippet during delete Volume and during GC: 2013-09-17 20:03:04,557 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null) ===START=== 10.146.0.129 -- GET command=deleteVolume&id=be37b4a9-f083-4d41-8654-3db5ff726255&response=json&sessionkey=FwuJPNi1MfU2slw1a6dgM9liVLA%3D&_=1379408947517 2013-09-17 20:03:05,243 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) SeqA 9-12329: Processing Seq 9-12329: { Cmd , MgmtId: -1, via: 9, Ver: v1, Flags: 11, [{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":41,"_loadInfo":"{\n \"connections\": []\n}","wait":0}}] } 2013-09-17 20:03:05,256 DEBUG [agent.manager.AgentManagerImpl] (AgentManager-Handler-2:null) SeqA 9-12329: Sending Seq 9-12329: { Ans: , MgmtId: 7652490870806, via: 9, Ver: v1, Flags: 100010, [{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] } 2013-09-17 20:03:05,293 DEBUG [cloud.user.AccountManagerImpl] (catalina-exec-23:null) Access granted to Acct[9adeb308-1a21-11e3-b1b5-06f5bc000016-admin] to Domain:1/ by AffinityGroupAccessChecker_EnhancerByCloudStack_185497a3 2013-09-17 20:03:05,377 INFO [cloud.resourcelimit.ResourceLimitManagerImpl] (catalina-exec-23:null) Discrepency in the resource count (original count=459320832 correct count = 2147483648) for type secondary_storage for account ID 2 is fixed during resource count recalculation. 2013-09-17 20:03:05,411 INFO [cloud.storage.VolumeManagerImpl] (catalina-exec-23:null) Expunging volume 96 from secondary data store 2013-09-17 20:03:05,418 DEBUG [storage.volume.VolumeServiceImpl] (catalina-exec-23:null) Marking volume that was never created as destroyed: Vol[96|vm=null|DATADISK] 2013-09-17 20:03:05,467 DEBUG [cloud.api.ApiServlet] (catalina-exec-23:null) ===END=== 10.146.0.129 -- GET command=deleteVolume&id=be37b4a9-f083-4d41-8654-3db5ff726255&response=json&sessionkey=FwuJPNi1MfU2slw1a6dgM9liVLA%3D&_=1379408947517 2013-09-17 20:11:49,466 DEBUG [cloud.storage.StorageManagerImpl] (StorageManager-Scavenger-1:null) Storage pool garbage collector found 0 templates to clean up in storage pool: pr 2013-09-17 20:11:49,473 DEBUG [cloud.storage.StorageManagerImpl] (StorageManager-Scavenger-1:null) Storage pool garbage collector found 0 templates to clean up in storage pool: p2 2013-09-17 20:11:49,497 DEBUG [cloud.storage.StorageManagerImpl] (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 0 templates to cleanup on template_store_ref for store: sec 2013-09-17 20:11:49,504 DEBUG [cloud.storage.StorageManagerImpl] (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 0 snapshots to cleanup on snapshot_store_ref for store: sec 2013-09-17 20:11:49,510 DEBUG [cloud.storage.StorageManagerImpl] (StorageManager-Scavenger-1:null) Secondary storage garbage collector found 1 volumes to cleanup on volume_store_ref for store: sec 2013-09-17 20:11:49,513 DEBUG [cloud.storage.StorageManagerImpl] (StorageManager-Scavenger-1:null) Deleting volume store DB entry: VolumeDataStore[2-96-2volumes/2/96/e28c14c2-6efe-3bec-aa85-0c1d8d4811e8.ova] So reopening the bug. > [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 > Assignee: Min Chen > Fix For: 4.2.1 > > Attachments: cloud.dmp, cloud.dmp, management-server.rar, > 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