Closed skyguy94 closed 10 years ago
Unfortunately that really seems like a DNS issue. Maybe there is a broken DNS cache in the pool?
I'd happily point vagrant at a local copy of the installer, but I haven't figured out how to do that yet.
You can set config.omnibus.install_url
in Vagrantfile or the OMNIBUS_INSTALL_URL
environment variable to point to a local, modified install.bat which could install a local copy of the Chef package.
I'll close the issue as I can't think of why this could be caused by this plugin. Feel free to reopen if you have other thoughts.
I was seeing it often enough, that I wanted to post it to see if others were having the same issue, but I didn't know where or how to post it in a meaningful way. Generally speaking, it does seem like a DNS issue. I switched to google's DNS servers and it is still happening. I'm headed out of town from Alabama to Michigan this week and I want to see if it is reproducible at my new location.
Specifically though, it doesn't seem like the plugin should be trying to extract from a failed download. I have the feeling that this is transient to the vm state, but no basis in fact for assuming that.
Would you be opposed to some retry logic with a delay and more powershell-isms?
param (
[Parameter(Mandatory=$true)]
[string]$version
)
Write-Output "Downloading Chef $version for Windows..."
$url = "#{url}?v=$version"
$dest = Join-Path Get-Location "chef-client-$version-1.windows.msi"
$retries = 3
while ($retries -gt 0) {
Try {
(New-Object System.Net.WebClient).DownloadFile($url, $dest)
} Catch [System.Exception] {
Write-Output "Problem downloading chef. Exception: $_"
$retries--
if ($retries -eq 0) {
Write-Output "Download failed. Aborting"
exit 1
}
Start-Sleep -s 10
}
}
Write-Output "Installing Chef $version"
msiexec /q /i $dest
I switched to google's DNS servers and it is still happening.
On the guest VM?
I'm not too familiar with Windows guests, but seems that the config.omnibus.install_url
can there be an URL to a locally hosted msi package. But seems that file paths probably won't work as the url is just passed to the generated bat file.
Would you be opposed to some retry logic with a delay and more powershell-isms?
What do you think, @schisamo and @jarig?
Ok, lmk. I'll submit a PR if you guys decide its ok.
I'm experiencing this issue too. My provider is Parallels and box is centos66. It was intermittent, but with when I started using parallels/ubuntu-14.04 it seems it's permanent. Needless to say, inside vm wget with chef.com works just fine.
When running
vagrant provision
using the VMWare provider on a Windows 8.1 host and Windows 8.1 client with chef omnibus installer, the install will fail intermittently, but often with the error:Gist of the debug log is here: https://gist.github.com/skyguy94/99abdc3966714cf09d0e
The interesting part is here:
Sometimes calling
vagrant provision
one or more times will get it into a working state, sometimes not. I haven't seen a clear reason as to why I get dns resolution in some cases and not in others. I'd happily point vagrant at a local copy of the installer, but I haven't figured out how to do that yet.This is happening on Windows, but it might be related to #88, #95, #96.