You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@aurora.apache.org by "Bill Farner (JIRA)" <ji...@apache.org> on 2014/05/30 22:37:02 UTC

[jira] [Commented] (AURORA-499) Interrupted vagrant provisioning leaves multiple VMs running

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

Bill Farner commented on AURORA-499:
------------------------------------

AFAIK there's nothing we can do save for avoiding aggressive {{git clean}} invocations.  Vagrant stores state in {{.vagrant/}} and otherwise doesn't know about VMs it previously created.

> Interrupted vagrant provisioning leaves multiple VMs running
> ------------------------------------------------------------
>
>                 Key: AURORA-499
>                 URL: https://issues.apache.org/jira/browse/AURORA-499
>             Project: Aurora
>          Issue Type: Bug
>          Components: Testing
>            Reporter: Maxim Khutornenko
>
> The following sequence results in a bizarre and non-deterministic behavior wrt vagrant testing:
> 1. vagrant up
> 2. ctrl+c before the provisioning finishes
> 3. git clean -fdx and go to step 1 again.
> The above leaves behind multiple VBoxHeadless instances of various readiness. All commands, including vagrant ssh, aurora create, scheduler UI refresh and etc. result in requests being routed to random boxes. In my case, I was able to create a job inside of one VM that routed to the scheduler in another VM. The UI was also behaving erratically receiving responses from different boxes (mixing old an new UI on different requests). 
> This smells like a vagrant bug and I am not sure what exactly we can do here short of "pkill -9 VBoxHeadless" before starting a new provisioning.



--
This message was sent by Atlassian JIRA
(v6.2#6252)