Set up Vagrant

[orenyk]

We should set up Vagrant so that we can ensure consistent development environments. This will require:

• remove 'Vagrantfile' from the .gitignore file
• set up and configure a proper Vagrantfile

This article might be useful.

[orenyk]

Notes:

• by default vagrant stores boxes in ~/.vagrant.d/, so if your data isn't stored on your C:\ drive in Windows (e.g. SSD), you have to make a symlink to store those files on a different drive
• the same is true for the default VirtualBox storage location, although this can be changed in the GUI preferences
• if you want to use Ubuntu 12.0.4 LTS x64 as our base box with Chef for provisioning, we have to use hashicorp/precise64 vs ubuntu/precise64 since the former doesn't include Chef

[orenyk]

Ok, the guide linked to above is not working, I'm getting a Chef error no matter which base box I use: You must specify at least one cookbook repo path. Calling it a night...

[dgoerger]

I understand the appeal of being able to use your native text editor and ssh into the VM headlessly (no-GUI for the VM), but we can already get consistent VM environments (actually, much more consistent because we won't have to worry about) with the vanilla VirtualBox export/import functions. A properly set up vagrant environment would also (I believe) finally allow Windows devs to test Reservations with Internet Explorer. I guess, if vagrant is hard to set up, I'm confused why we're pursuing it when it really does just use VirtualBox as a backend.

Have we considered Docker or vanilla VirtualBox, instead?

[orenyk]

I feel like the Vagrant VMs are just much lower overhead since they don't have a lot of the UI stuff running in the background. I also feel like the difference between setting up a VM image for vanilla VirtualBox and for Vagrant is pretty small; if I can't get it working tonight we can revisit the idea but it really shouldn't be so hard. As far as I can tell, Docker is more suited to production environments (see here), but it would also require running a VM when used on Windows anyway (see here) so I'm not sure how it would be better.

I'm torn; I've liked having my development environment completely isolated within my VirtualBox VM but at the same time it's definitely resulted in a slower system. I'm still getting used to dealing with Git on Windows (and trying to find a good shell to work in) but I feel like Vagrant would ultimately be simpler and easier to work with (assuming proper use of version control).

[dgoerger]

Docker would be better in the sense that we would be able to upload and download entire server containers to/from Jenkins for testing, devving, and deployment. (i.e, no more asking Mike for the database, it would be a simple download and running of the entire affected container for perfect simulation) It would, unlike vagrant, also not require Linuxers to run a full VM (although I admit I do that anyway). :P

How would Windows users using Windows editors work wrt CLRF under vagrant? We'd have to be extra careful about making sure Windows users sanitize their systems before we allow them to push any code, if using a Windows-based editor. @mnquintana has some pretty strong feelings against using Windows as a dev env, and I don't know how vagrant solves these problems, if at all. We should check with him before pursuing vagrant too far.

[orenyk]

I hear what you're saying; I think the CLRF issue can be dealt with through Git, but it may be better for people to have consistent complete development environments regardless. That being said, since not everyone may want to dual-boot, if we can give people an option for using their desired OS for coding / manual testing and ensure a consistent runtime environment, that could still be valuable as an alternative.

I'm trying to base a new attempt on this repo, hopefully this will work better than figuring out Chef (I felt way out of my depth there... oy).

[orenyk]

Pushed a new version of the Vagrantfile with some companion shell scripts to this branch. It's currently trying to install Ruby (and has been for 20 mins)... I'm not sure why it's taking so long but I'm going to leave it overnight and see if it even finishes. I'm pretty close to giving up on this, it just doesn't feel like it will be worth it. More updates to come!

[orenyk]

Woo hoo! I think it worked! Not sure why it was taking so long, just re-running to try and fix a few final errors but hopefully we have an initial working Vagrant setup.

[orenyk]

Ok, Ruby version 2.1.2 installed fine but 2.1.1 is failing to build. It looks like there's a weird YAML dependency difference between the two versions, but I don't know if that explains why the build is failing:

==> default: Installing ruby-2.1.1...
==> default: BUILD FAILED
==> default: Inspect or clean up the working tree at /tmp/ruby-build.20140723070439.7674
==> default: Results logged to /tmp/ruby-build.20140723070439.7674.log
==> default: Last 10 log lines:
==> default:                                     ^
==> default: readline.c: At top level:
==> default: readline.c:634:1: warning: 'readline_pre_input_hook' defined but not used [-Wunused-function]
==> default:  readline_pre_input_hook(void)
==> default:  ^
==> default: make[2]: *** [readline.o] Error 1
==> default: make[2]: Leaving directory `/tmp/ruby-build.20140723070439.7674/ruby-2.1.1/ext/readline'
==> default: make[1]: *** [ext/readline/all] Error 2
==> default: make[1]: Leaving directory `/tmp/ruby-build.20140723070439.7674/ruby-2.1.1'
==> default: make: *** [build-ext] Error 2
==> default: rbenv: version `2.1.1' not installed

Thoughts?

[dgoerger]

There's a ruby-build workaround posted here. That help? It looks like the readline error only affects 2.1.0 and 2.1.1, and only on some machines.

[dgoerger]

@caseywatts mentioned that there had been some problems with vagrant during the spring course. I'm setting up a USB/dualboot solution right now, @orenyk might you want to test the result later today?

[jasonkliu]

I've used Vagrant a little, here's what I've found:

I use the precise32 box, which is a standard Ubuntu 12.04 LTS 32-bit box.
The precise64 box is 64-bit but I've had a lot of problems with it so I don't recommend using it.

Here's the portion of the Vagrantfile I use (I don't really use any options):

# -*- mode: ruby -*-
# vi: set ft=ruby :
# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.
  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "hashicorp/precise32"
end

How to set everything up:

1. install vagrant from website or brew cask install vagrant after you have homebrew cask installed by doing brew install caskroom/cask/brew-cask

2. put the Vagrantfile (no extension in the directory you want. Be careful because you can't go up directories, so put it at the ROOT of where you want to develop.
   for example, if this is your structure:
   /Users/jason/Github contains directories:
   shifts/ reservations/ blah/ blah/ blah/
   Drop the Vagrantfile in /Users/jason/Github so it has access to shifts/ reservations/ etc.
   It doesn't have access to /Users/jason.

3. vagrant up && vagrant ssh
   Basically logs you into vagrant then ssh's you into the machine.
   I don't have use for a GUI so that works for me.
   sudo apt-get update && sudo apt-get upgrade # update everything
   sudo apt-get install -y git vim # -y flag says "YES" so you don't have to keep writing
   cd /vagrant # This is your shared folder, now you can access all of the folders where your Vagrantfile is

4. vagrant halt when you're done, vagrant destroy will kill everything and restore the machine to pristine state. I don't like vagrant suspend because it still eats your RAM.

ask if you have any questions :)
btw github on windows is kinda terrible. I fully support vagrant @dgoerger
Oh yeah, you don't need Cygwin etc for this. Just cmd.exe will work. I might have some weird stuff like git bash installed but it seems to work out okay. I tried out mingw and found it underwhelming.

[orenyk]

Thanks @jasonkliu that's really helpful! Have you figured out a way to make the windows command line not suck so much? :-P

[dgoerger]

I generally advise against 32bit OSes; they're still supported by the Linux community, but it's definitely a second-class citizen and undergoes less testing than 64-bit versions of the software. (Within a few years I expect ARM to be better supported than 32-bit for newer applications.) You should definitely never use Ubuntu 12.04 anymore; that's been deprecated since April in favor of 14.04 LTS and will cause more problems with package versions than are really worth putting up with.

I noticed that your instructions are specific to OS X, unless there's also a homebrew for Windows? cmd.exe, cygwin, and mingw are each Windows-based, but I've only heard of homebrew for Mac and your cited folder structure is suspiciously Mac-like, so I'm confused how these instructions would work.

[dgoerger]

also, we should defer to @caseywatts and @mnquintana, who have had experience with Windows developers attempting to use vagrant in a class setting.

[jasonkliu]

@dgoerger The process is exactly the same for windows except for step 1 I just installed from the website (the binary from vagrantup.com). It worked fine for me on Windows 8 - what were the issues that happened?
Er... I have a specific Github folder on OSX, but I don't have a similar folder on Windows. Basically put the Vagrantfile anywhere and you can access all subdirectories with the vagrant virtual machine.
By the way, 12.04 LTS has 5 years' worth of support which ends in 2017.. I wouldn't necessarily call it 'deprecated'.

@orenyk In regards to the Windows comand line, no dice. Here's a couple options I've tried:
Cygwin - Running the 'setup.exe' is kinda inconvenient to install packages every time, and the font kinda bugs me for some reason. (I guess this happens with all Windows terminals). I guess it's the most "bash-like" by itself.
cmd.exe - Pretty terrible by itself, but you can use Vagrant with it which makes it somewhat usable. Note: I have some weird stuff installed in my cmd.exe. For example, installing the Github for Windows app installs some bash commands in cmd.exe, and installing NodeJS from the binary also gives you some other bash commands. Now my cmd.exe kinda functions like bash, but with quotes around file paths. It's super strange.
mingw - Gives you gcc, make, etc. It's not really a shell, though, so you can use the included msys, which is kinda like a cut down shell. This is only really good if you like to compile stuff with gcc - no real full shell functionality.
Powershell - supposed to be good but I never tried it.
Others - https://stackoverflow.com/questions/440269/

sadly, all the options I've tried aren't great 💭

[jasonkliu]

oh by the way, if you want to switch to linux, here are some short recommendations, from beginner to expert difficulty:

ubuntu:
pros: easiest to use, most community support if things go wrong (largest community)
cons: ugly ui, kinda slow

crunchbang:
pros: similarly easy to use (it's based off debian), looks cool, super fast, can access everything from right click menu (most productive)
cons: smaller community

arch linux:
pros: configure everything yourself (this is kinda a con if you aren't a 'master' at linux), most up-to-date packages, best wiki ever, you learn a ton about linux
cons: configure everything yourself, it makes you not want to use a gui ever

[squidgetx]

I would recommend mint over ubuntu as a beginner distro personally, as it doesn't have spyware or the ugly ui.

Back on topic, how's the virtual usb @dgoerger ?

[dgoerger]

@jasonkliu thanks for the clarification! I was just worried seeing all of the Mac instructions, because Oren's trying to get it working on Windows, and homebrew won't help there at all. :P Good to know the instructions on the vagrant website are sufficient for Windows. 😀

Ubuntu 12.04 LTS has five years' support, sure, but that's misleading because that just means Canonical is willing to backport major (and only major) security fixes for that long. The version of git for example in 12.04 is ancient (1.7 vs the much-improved upstream 2.0.3), and it's only going to get worse (read: more outdated) staying on 12.04. It's deprecated in the sense that it should not be used for new installations anymore or used in any instance where any version of software not already three years out-of-date is desired. 😉

I'm a big fan of Fedora for the reason of newer packages and ease of packaging newer versions locally into rpms, although I did use Ubuntu and Debian for five years before switching last November. Debian-based OSes are usually more stable than Fedora or Arch, but that Debian-testing phase comes at the cost of everything being a year out-of-date by the time it's released as a final product.

+1 Mint's superior default UI and lack of built-in spyware (relative to Ubuntu 12.10+). The FSF denounced Ubuntu as spyware back in 2012, and I agree with this assessment. There was never any reason to begin automatically submitting desktop search queries to Amazon.com (the same search to find your local programs and files), but Canonical did it anyway.

@squidgetx @orenyk: I GOT THE USB/VM TO WORK(!). It required some investigation to get it booting off a USB (it must be booted into rescue mode and then from there you need to reinstall the latest kernel to have it work with real physical hardware versus virtualized hardware), but it works! Once we have a working USB, we can clone it nbd. It's horrifically slow opening programs off USB 2.0 (no surprise there), but has regular snappy OS speed once the program's loaded into memory. I'm going to make a few more tweaks to the image before uploading it for wider testing. 😀

[orenyk]

I checked out the USB with @dgoerger today and it booted without issue on my laptop and looked great! If we upgrade to Ruby 2.1.2 I think I'll also have a working Vagrant setup, but I'd strongly recommend the USB / VM route. I'll leave this open pending the Ruby upgrade and verification.

[orenyk]

In the interest of time, and given the fact that we currently have a beautiful VM to work with thanks to @dgoerger, I'm closing this issue. When it comes time to export the app we can revisit this question, but I think that given sufficiently well-documented dependencies we don't have to provide a Vagrant setup.