Linux setup fixes

[jswu]

Tested on a fresh install of Ubuntu 12.04 inside a Vagrant vm (VirtualBox). Only remaining issue is that mongod seems to start up automatically after install or something, which binds to the address that we need.

Killing the mongod process and then running make local works just fine.

[jlfwong]

As mentioned in #66, the tests rely on chromedriver being in the path - could you add it to the setup script and test it in the VM?

May want to use https://gist.github.com/mikesmullin/2636776 as a starting point, but I think we want to grab http://chromedriver.storage.googleapis.com/2.9/chromedriver_linux64.zip instead of the zip listed in that gist.

[divad12]

For the mongo issue, should we sudo service mongodb stop or something after installing mongo?

Also, I think the first years mentioned that running make local the first time would fail because mongo would take a very long time to start the first time, which would cause our Flask app to crash, which would cause local_server.sh to then kill all child processes and terminate. Did you experience anything like this?

Also, were you able to test up to make init_data?

[divad12]

Also, did your Ubuntu install came with a bunch of *-dev packages installed already? I think Gabriel had to install a bunch of such packages.

[jswu]

@phleet Added chromedriver, but couldn't test it properly in my headless VM.

@divad12
1)sudo service mongo stop sound like a great idea. I added it.
2) make init_data worked fine for me.
3) I used the Ubuntu 12.04 32-bit image hosted by vagrant http://files.vagrantup.com/precise32.box and did not have to install any *-dev packages. Not sure if vagrant does anything special on top of the base image, but I doubt it.

[jlfwong]

Would you mind trying to run this whole thing from scratch and see if can complete installation and bootup? I'm especially curious about the sudo service mongo stop part working.

[jswu]

I ran the whole thing from scratch after each set of changes to ensure everything worked. I'll rebase onto master and retest one more time, just to be sure.

[divad12]

Sweet! Would it be easy to test on another distro? If not, that's totally fine, let's get this in first.

(I just recall Gabriel ran into problems like having to download zlib and some *-dev packages...)

[jswu]

Since we use apt-get, we support only distros like Debian/Ubuntu out of the box (and not CentOS/Fedora, which uses yum). I'll leave yum support for a future PR.

Do you know what distro and version Gabriel was running?

[divad12]

Not sure (but it was Debian-based). Let's point him to this PR after we open-source.

[jswu]

Tested again, and make install runs smoothly. make local also successfully starts up a server. make init_data also works as expected.

[divad12]

Awesome. LGTM.

[jswu]

I also just ran into the problem where mongo took too long to start and caused Flask to crash. I ran make local several times, but it crashed each time. I then ran mongod --config config/mongodb_local.conf manually (to confirm that mongo can start) and killed it. Then make local started working again.

The only things I did were

1. Install git, make, clone the repo
2. Run make install
3. Wait 2 hours
4. Run make local
   I've previously run through this scenario several times (without part 3), but haven't run into this until now...

I suppose we could monitor one of mongo's log files and start Flask only after we know mongo has started. Or we could just sleep a few seconds after starting mongod. I'm leaning towards the latter. What do you think @divad12?

[divad12]

So, I believe this is only an issue with starting up Mongo with our config for the first time on Linux. Since this is only a one-time issue, I'd rather not sleep a few seconds in local_server.sh every time, especially since "few seconds" might not be enough. If we want a simple solution, we can try running mongod --config config/mongodb_local.conf & in the linux setup script, print something like "warming up mongo. Sorry, this might take a while, so please do 50 push-ups now while you wait", sleep a while, then kill the backgrounded mongod process.

I know, really gross hack too, but at least it won't affect each run of local_server.sh....

[jswu]

I don't know how to repro this issue and, although it looks like it's fine after we "warm up" mongo, I don't know for sure.

If it's consistently (and randomly) an issue, we could perform the sleep only when we're on Linux.

I agree with your approach and will implement that for now.

[divad12]

@jswu Easiest way to repro is probably re-provision your vagrant image to its initial state that does not have mongo or anything else installed.

[divad12]

Oh sorry, I just saw that you wrote "I've previously run through this scenario several times (without part 3), but haven't run into this until now." Derp, can't read.

[jswu]

I'll merged this for now, and deal with mongo in a separate PR later (since Linux setup is completely broken without this PR)