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 Wed, 13 Jul 2016 09:12:20 GMT

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

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

Github user aledsage commented on a diff in the pull request:

    https://github.com/apache/brooklyn-server/pull/211#discussion_r70590130
  
    --- Diff: software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/MachineLifecycleEffectorTasks.java
---
    @@ -709,7 +712,26 @@ protected void doStop(ConfigBag parameters, Callable<StopMachineDetails<Integer>
     
             DynamicTasks.queue("pre-stop", new PreStopCustomTask());
     
    +        // BROOKLYN-263:
    +        // With this change the stop effector will wait for Location to provision so
it can stop it.
    +        // It will not retry if non-jclouds location is used in the entity.
             Maybe<MachineLocation> machine = Machines.findUniqueMachineLocation(entity().getLocations());
    +        if (Boolean.TRUE.equals(entity().sensors().get(Attributes.JCLOUDS_PROVISIONING_STARTED))
    +                && machine.isAbsent()) {
    +            entity().sensors().set(Attributes.JCLOUDS_PROVISIONING_STARTED, null);
    +            Repeater.create("Wait for a machine to appear")
    +                    .until(new Callable<Boolean>() {
    +                        @Override
    +                        public Boolean call() throws Exception {
    +                            return Machines.findUniqueMachineLocation(entity().getLocations()).isPresent();
    +                        }
    +                    })
    +                    .every(Duration.THIRTY_SECONDS)
    --- End diff --
    
    Feels like strange times to use. Why only check every thirty seconds? That means we might
take 29 seconds longer than we should have. The call to `getLocations()` should be cheap,
so doing it every second seems fine.


> 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