Aled Sage created BROOKLYN-264:
----------------------------------
Summary: 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:
```
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)
```
>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)