Problem Running Vagrant up

[ThibautGery]

When running vagrant up I get the following error :

==> default: -- downloading...
==> default:      src='https://openresty.org/download/openresty-1.9.7.4.tar.gz'
==> default:      dst='/vagrant/build/work/src/openresty-1.9.7.4.tar.gz'
==> default:      timeout='none'
==> default: CMake Error at openresty-stamp/download-openresty.cmake:9 (file):
==> default:   file DOWNLOAD HASH mismatch
==> default: 
==> default:     for file: [/vagrant/build/work/src/openresty-1.9.7.4.tar.gz]
==> default:       expected hash: [6e2d4a39c530524111ea50e3de67043a]
==> default:         actual hash: [d41d8cd98f00b204e9800998ecf8427e]
==> default: 
==> default: 
==> default: 
==> default: make[2]: *** [build/work/src/openresty-stamp/openresty-download] Error 1

edit : it seems that I get a different error each time i run vagrant up:

==> default: ---- Begin output of "bash"  "/tmp/chef-script20160530-7985-qh58ou" ----
==> default: STDOUT: [  2%] Built target ruby
==> default: [  3%] Built target bundler
==> default: [  4%] Built target api_umbrella_static_site
==> default: [  5%] Built target lua_resty_shcache
==> default: [  7%] Built target openssl
==> default: [  8%] Built target libgeoip
==> default: [  9%] Built target ngx_dyups
==> default: [ 11%] Built target pcre
==> default: [ 13%] Built target ngx_txid
==> default: [ 13%] Performing configure step for 'openresty'
==> default: /bin/sh: /vagrant/build/work/src/openresty/configure: No such file or directory
==> default: make[2]: *** [build/work/src/openresty-stamp/openresty-configure] Error 127
==> default: make[1]: *** [CMakeFiles/openresty.dir/all] Error 2
==> default: make: *** [all] Error 2
==> default: STDERR: 
==> default: ---- End output of "bash"  "/tmp/chef-script20160530-7985-qh58ou" ----
==> default: Ran "bash"  "/tmp/chef-script20160530-7985-qh58ou" returned 2
==> default: [2016-05-30T09:05:37+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

==> default:   cookbook_name :phantomjs
==> default:       recipe_name "source"
==> default:     
==> default:   owner "root"
==> default:       group "root"
==> default: 
==> default:       mode "0644"
==> default:     
==> default:   checksum "86dd9a4bf4aee45f1a84c9f61cf1947c1d6dce9b9e8d2a907105da7852460d2f"
==> default:     
==> default:   not_if { #code block }
==> default:     end
==> default:     
==> default: 
==> default: 
==> default: [2016-05-30T13:49:21+00:00] INFO: Running queued delayed notifications before re-raising exception
==> default: 
==> default: Running handlers:
==> default: [2016-05-30T13:49:21+00:00] ERROR: Running exception handlers
==> default: Running handlers complete
==> default: 
==> default: [2016-05-30T13:49:21+00:00] ERROR: Exception handlers complete
==> default: Chef Client failed. 14 resources updated in 32 minutes 23 seconds
==> default: [2016-05-30T13:49:21+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
==> default: [2016-05-30T13:49:21+00:00] ERROR: remote_file[/usr/local/src/phantomjs-2.1.1-linux-x86_64.tar.bz2] (phantomjs::source line 36) had an error: Chef::Exceptions::ContentLengthMismatch: Response body length 8581669 does not match HTTP Content-Length header 23415665.
==> default: [2016-05-30T13:49:21+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

I am looking to run the chef script inside the virtual machine, where will a find the cookbook ?

[ThibautGery]

It works well on the CI but not on my vagrant VM

[GUI]

Hm, so the hash of d41d... you're getting is the hash of an empty file (http://stackoverflow.com/q/10909976). So it seems like somehow the file download failed (yet an empty version of the file is in place). If you manually delete the empty file (rm /vagrant/build/work/src/openresty-1.9.7.4.tar.gz), and try vagrant provision, that should attempt to pickup the make process where it left off. With the old file gone, it should try to re-download the file.

Hopefully that will do the trick, but if you continue to get an empty file, then something may be amiss with OpenResty's site (it continues to work for me, but maybe it's being blocked on your network, or some invalid geo-based mirror?). If you continue to get this invalid empty file, can you try running curl -vOL "https://openresty.org/download/openresty-1.9.7.4.tar.gz" and posting its output?

[ThibautGery]

@GUI I updated my issue. I am getting a different error each time I run vagrant up. If it happens only on my computer I will look into it but I would like to know the output of the following commands on your computer:

vagrant destroy
vagrant up

The error could come from the network which is not really good.

[GUI]

On a fresh setup, I did hit an issue with a gem dependency we were depending on being yanked. I fixed that in 46387a6.

However, after fixing that, I was able to successfully do a vagrant destroy and then vagrant up on a fresh git clone without any issues.

These other errors you're getting are rather odd. I'm not sure what would lead to /vagrant/build/work/src/openresty/configure: No such file or directory. The second error with phantomjs and Response body length 8581669 does not match HTTP Content-Length header 23415665 one looks like another partial download, though.

If the your network downloads are being finicky, one thing I'd suggest is doing a vagrant provision after any failures (rather than destroying the VM and starting again). This will pickup the build process where it left off, so you may have better luck in eventually getting everything to download successfully with a couple provision attempts (or at least this should lead to a more consistent failure, rather than debugging different things that seem to be failing to download each time).

Sorry for the development setup trouble, but let us know if you're still encountering any issues getting it setup.

[ThibautGery]

It worked correctly. I suppose that during the first run, the network was flaky and some downloaded files were corrupted and they stayed un the directory (even after a vagrant destroy) I just cleaned the repository

[ThibautGery]

The web server doesn't start correctly :

$ tail /var/log/api-umbrella/web-puma/current
2016-05-31T14:57:37.84076 starting web-puma...
2016-05-31T14:57:38.09394 bundler: command not found: puma
2016-05-31T14:57:38.09396 Install missing gem executables with `bundle install`

I have tried to to run

• bundle install in /vagrant/src/api-umbrella/web-app
• sudo bundle install in /opt/api-umbrella/embedded/apps/core/current/src/api-umbrella/web-app

Where is the current directory from the source are used ?

[GUI]

Ah, excellent point about the build files sticking around after a vagrant destroy. That doesn't seem very intuitive and potentially problematic in situations like this. I've fixed that in 31a5cb2 so that we now cleanup any of these build files before brining the box up for the first time. Hopefully this behavior will be better, and thanks for pointing that out!

As for the puma start issues, that's an odd one I haven't seen before (and I just did another vagrant destroy and up again without issues). Could you try posting the following contents?

$ vagrant ssh
$ cat /vagrant/src/api-umbrella/web-app/.bundle/config
$ ls -l /vagrant/build/work/vendor/bundle/ruby/2.2.0/gems/

Or here's a couple of steps that should theoretically re-bundle and install the gem dependencies as expected, if you want to try these:

$ vagrant ssh
$ touch /vagrant/src/api-umbrella/web-app/Gemfile
$ cd /vagrant
$ make
$ sudo make install
$ sudo /etc/init.d/api-umbrella restart

If that doesn't work, then please post the contents of those first couple commands.

Sorry for the trouble in getting this setup, but thanks for your patience, and hopefully we're almost there.

[GUI]

And as a quick heads up, I've just made a couple of additional tweaks to the latest Vagrantfile that should hopefully smooth things out and resolve a couple of small issues. But please let us know if you're still encountering any errors.

[ThibautGery]

I destroyed the VM and recreated it with your tweaks, it worked ! It must have been either your tweaks or my erratics action on the VM.
Thanks, I will test #246 tomorrow