brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
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 11:15:20 GMT


ASF GitHub Bot commented on BROOKLYN-264:

Github user bostko commented on a diff in the pull request:
    --- Diff: software/base/src/main/java/org/apache/brooklyn/entity/software/base/lifecycle/
    @@ -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);
    --- End diff --
    @aledsage do you have an idea how can I tell the stop task that the provisioning started
other than the sensor flag. I feel like the code will need serious refactoring in order stop
task to know earlier about the jclouds node.
    The entity knows only about the machine location. It doesn't know about the LocationProvisioner.

> Stop app while VM still being provisioned: vm is left running when app is expunged
> ----------------------------------------------------------------------------------
>                 Key: BROOKLYN-264
>                 URL:
>             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(
>     org.jclouds.compute.internal.BaseComputeService.createNodesInGroup(
>     org.jclouds.ec2.compute.EC2ComputeService.createNodesInGroup(
>     org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(
>     org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(
>     org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(
>     org.apache.brooklyn.util.core.task.DynamicSequentialTask$
>     org.apache.brooklyn.util.core.task.BasicExecutionManager$
> {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

View raw message