aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Farner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AURORA-499) Interrupted vagrant provisioning leaves multiple VMs running
Date Fri, 30 May 2014 20:37:02 GMT

    [ 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)

Mime
View raw message