Open zxaos opened 8 years ago
This sort of has a bit of a story behind it.
We (as in @danbohea and myself) were toying around with some things a year ago and tried to find out how to detect if the box was up or not. After a few hours of research and some messing about I found that using the hosts.ini file was the only way to detect if the box was running. Creating the file on launch and removing the file on destroy/halting and then using the existence of the file as a way to detect if the box was running when running triggers.
For some reason, and I can't remember why now, we stripped a lot of this out of the Vagrant file. I think it may have been to do with breaking other components, which mean that if the hosts.ini file wasn't present then things broke in interesting ways. Like it wouldn't "up" or destroy the box correctly (although I can't remember why exactly). The issue in question was this #192 , which resulted in the commit: https://github.com/hashbangcode/vlad/commit/7905afe4aa2adc494cb74ca3df480dbd9e4c2936
So, solutions:
For some reason, and I can't remember why now, we stripped a lot of this out of the Vagrant file.
I think the reason for much of that being stripped out of the Vagrantfile was the introduction of the vagrant-hostsupdater plugin which now handles a lot of what was previously going on with the presence/absence of the host.ini file.
If, by some miracle, there happens to be a way to detect if the box is running then use this.
Could we check the hosts file on the host system against certain regex to see if the box is up possibly? I just quickly checked my own file and noticed a couple entries for VMs that aren't up but they are all Vlad dev VMs that have likely gone awry in testing and general mucking about - by no means "normal use".
Could we check the hosts file on the host system against certain regex to see if the box is up possibly?
Sounds like it might work :) Especially as the hosts file is managed by a Vagrant plugin.
If you delegate_to: 127.0.0.1
in Ansible you could simply parse the output of vagrant status --machine-readable
, no?
The vagrant destroy scripts assume the VM is running so they try to dump the DB, which fails and takes longer than it needs to when the VM isn't on.