[GitHub] brooklyn-server issue #211: BROOKLYN-264 Stop app while VM still being provi...

[aledsage <gi...@git.apache.org>]

Github user aledsage commented on the issue:

    https://github.com/apache/brooklyn-server/pull/211
  
    My comments so far are bike-shedding.
    
    Looking at the big picture, I need to think more about:
    
    * How should we trigger the delete, so that it safely handles success and failure of provisioning? Options include:
      * As you've done here, have `stop()` wait for the machine to be set; but abort if start() fails.
      * Mark the entity's internal state as "requiring machine-release", and have the start() code immediately release the machine. But we'd still need `stop()` to wait for that to be done, otherwise we might go on to unmanage the entity and thus cancel the tasks.
    
    * For speed:
      * Can we use the jclouds event bus to be told of the VM's id long before jclouds has returned from the provisioning call? @andreaturli what do you think?
      * Can we tell the `JcloudsLocation` instance that the provisioning has been aborted (this would allow us to avoid waiting-for-sshable, etc). Not quite sure how best to do that.
    
    We can ignore the speed issue for now, unless there is a quick win that greatly speeds things up. The main thing is to get it functionally correct, and with clean code.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---