Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Tue, 3 May 2016 05:51:12 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12964530.1462254284000.94349.1462254672822@Atlassian.JIRA>
In-Reply-To: <JIRA.12964530.1462254284000@Atlassian.JIRA>
References: <JIRA.12964530.1462254284000@Atlassian.JIRA> <JIRA.12964530.1462254284365@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-9374) Replace timer.sleep in
 host-delete method to correct timing problem
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 03 May 2016 05:51:14 -0000


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

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

GitHub user mike-tutkowski opened a pull request:

    https://github.com/apache/cloudstack/pull/1529

    Marvin: Replace a timer.sleep(30) with pulling logic

    https://issues.apache.org/jira/browse/CLOUDSTACK-9374
    
    From the ticket:
    
    In the base.py file, there is a Host class with a delete instance method.
    
    This method first attempts to transition the host into the maintenance resource state.
    
    The first step in this process is to transition the host into the prepare-for-maintenance resource state.
    
    A while later, the host can be transitioned completely into the maintenance resource state.
    
    In an attempt to wait for this transition to occur, the delete method has a timer.sleep(30) call.
    
    The hope is that the host will have transitioned from the prepare-for-maintenance resource state to the maintenance resource state within 30 seconds, but this does not always happen.
    
    We should correct this problem by putting in logic to query the management server for the resource state of the host. If it's in the expected state, move on; else, sleep for a bit and try again (up to a certain limit).

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/mike-tutkowski/cloudstack marvin_replace_sleep

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/cloudstack/pull/1529.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #1529
    
----
commit 6945d3780b2a01c28ab08d66e0a320082ca4709e
Author: Mike Tutkowski <mike.tutkowski@solidfire.com>
Date:   2016-05-03T04:38:55Z

    Replace a timer.sleep(30) with pulling logic

----


> Replace timer.sleep in host-delete method to correct timing problem
> -------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9374
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9374
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: marvin
>    Affects Versions: 4.9.0
>         Environment: N/A
>            Reporter: Mike Tutkowski
>            Assignee: Mike Tutkowski
>             Fix For: 4.9.0
>
>
> In the base.py file, there is a Host class with a delete instance method.
> This method first attempts to transition the host into the maintenance resource state.
> The first step in this process is to transition the host into the prepare-for-maintenance resource state.
> A while later, the host can be transitioned completely into the maintenance resource state.
> In an attempt to wait for this transition to occur, the delete method has a timer.sleep(30) call.
> The hope is that the host will have transitioned from the prepare-for-maintenance resource state to the maintenance resource state within 30 seconds, but this does not always happen.
> We should correct this problem by putting in logic to query the management server for the resource state of the host. If it's in the expected state, move on; else, sleep for a bit and try again (up to a certain limit).


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