brooklyn-dev 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] (BROOKLYN-264) Stop app while VM still being provisioned: vm is left running when app is expunged
Date Mon, 18 Jul 2016 20:16:20 GMT

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

ASF GitHub Bot commented on BROOKLYN-264:
-----------------------------------------

GitHub user aledsage opened a pull request:

    https://github.com/apache/brooklyn-server/pull/266

    BROOKLYN-264: refactor wait-for-provision

    We now mark the internal state as provisioning entirely in 
    MachineLifecycleEffectorTasks, and that is also where we wait for it
    on stop(). This also allows us to test it as a unit test, rather than
    needing a jclouds live test.
    
    @bostko can you please review?

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

    $ git pull https://github.com/aledsage/brooklyn-server brooklyn-264_refactor

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

    https://github.com/apache/brooklyn-server/pull/266.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 #266
    
----
commit e74bc778cca888716b3d3cfeb27e30b394b8179e
Author: Aled Sage <aled.sage@gmail.com>
Date:   2016-07-18T20:12:59Z

    BROOKLYN-264: refactor wait-for-provision
    
    We now mark the internal state as provisioning entirely in
    MachineLifecycleEffectorTasks, and that is also where we wait for it
    on stop(). This also allows us to test it as a unit test, rather than
    needing a jclouds live test.

----


> Stop app while VM still being provisioned: vm is left running when app is expunged
> ----------------------------------------------------------------------------------
>
>                 Key: BROOKLYN-264
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-264
>             Project: Brooklyn
>          Issue Type: Bug
>    Affects Versions: 0.9.0
>            Reporter: Aled Sage
>
> A customer deployed an app to AWS, but while the VM was still starting up they stopped
(and thus expunged) the app. The app disappeared from the Brooklyn web-console, but the starting
VM was left behind in AWS.
> This is simple to reproduce:
> 1. deploy a simple blueprint, such as:
> {noformat}
> location: aws-ec2:us-east-1
> services:
> - type: org.apache.brooklyn.entity.machine.MachineEntity
> {noformat}
> 2. wait for the VM to appear in the AWS web-console (with state "initialising")
> 3. call the {{stop}} effector on the top-level app.
> ---
> Looking at the {{start}} task that was executing at the time when {{stop}} was called,
below is the thread's stack trace:
> {noformat}
> Provisioning machine in JcloudsLocation[AWS Virginia:AAAAAAAAAAAAAAAAAAAA/aws-ec2:us-east-1@eyNrLIo5]
> Task[provisioning (AWS Virginia)]@MJITkjw0
> Submitted by SoftlyPresent[value=Task[start]@tKw0qJET]
> In progress, thread waiting (notify) on java.util.concurrent.CountDownLatch$Sync@2ed5be36
> At: org.jclouds.concurrent.FutureIterables.awaitCompletion(FutureIterables.java:149)
>     org.jclouds.compute.internal.BaseComputeService.createNodesInGroup(BaseComputeService.java:214)
>     org.jclouds.ec2.compute.EC2ComputeService.createNodesInGroup(EC2ComputeService.java:149)
>     org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(JcloudsLocation.java:726)
>     org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(JcloudsLocation.java:616)
>     org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:406)
>     org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:396)
>     org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(Tasks.java:98)
>     org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:380)
>     org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:364)
>     org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:359)
>     org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:519)
> {noformat}
> From this, we can see that we are still calling jclouds. This means that jclouds has
not yet returned to Brooklyn the VM's id. It also means that the {{MachineEntity}} will not
have been given a {{JcloudsSshMachineLocation}} instance. 
> When {{stop}} is called on the {{MachineEntity}}, it doesn't have a machine location
instance so it doesn't have anything to ask to stop. This is why the VM is left running.



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

Mime
View raw message