cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-8655) [Browser Based Upload Volume] Partially uploaded volumes are not getting destroyed as part of storage GC
Date Tue, 21 Jul 2015 09:13:04 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634818#comment-14634818
] 

ASF GitHub Bot commented on CLOUDSTACK-8655:
--------------------------------------------

Github user koushik-das commented on the pull request:

    https://github.com/apache/cloudstack/pull/611#issuecomment-123227873
  
    Test browser based incomplete volume upload, followed by SSVM destroy. Volume should go
to UploadAbandoned/Error state and get cleaned up. ... === TestName: test_browser_upload_volume_incomplete
| Status : SUCCESS ===
    ok
    
    ----------------------------------------------------------------------
    Ran 1 test in 351.347s
    
    OK



> [Browser Based Upload Volume] Partially uploaded volumes are not getting destroyed as
part of storage GC
> --------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-8655
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8655
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions: 4.6.0
>            Reporter: Koushik Das
>            Assignee: Koushik Das
>             Fix For: 4.6.0
>
>
> Repro steps:
> 1. Initiate getUploadParamsForVolume API and do not or partially upload the volume.
> 2. Destroy SSVM.
> 3. Wait for the volume entry to get into UploadError/UploadAbandoned state in the volumes
table in DB.
> 4. Verify that this volume continues to remain in that state and doesn't get GC'ed (displayed
as part of listVolume API).
> As part of volume sync, that runs as part of SSVM start-up, the entry in volume_store_ref
table was getting deleted. Volume GC relies on this entry to move volume to destroyed state.
Since the entry was getting deleted, GC thread never moved the volume from UploadError/UploadAbandoned
to Destroyed.
> The fix is to not remove the volume_store_ref entry as part of volume sync and let the
storage GC thread handle the clean up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message