Streamline VM to run off host system repository

[btbonval]

Originally I thought it would be a good idea to merely clone the host system's repository to effect a level of isolation of the virtual machine from the host system.

My own workflow with git is surprisingly complex and annoying because of this, but I have been getting on alright.

Now other users have noted the work flow issues caused by this as well. Perhaps isolation does more harm than good.

Presently the VM clones the host system repo (found in /vagrant) into the homedir and soft links the homedir to /var/www/karmaworld.

It might be considerably less hassle for the entire world if /vagrant, a mount point of the user's repo on the host system, was soft linked to /var/www/karmaworld. This means changes on the host system would be immediately reflected by the VM (pending the usual sort of gunicorn restarts) without the need for git to be a middleman.

[btbonval]

The concept of isolating from the host system is pretty much lost because the /vagrant directory is a host mount.

The soft link might not be possible if the mount is not-transparent, that is it shows up as a separately mounted file system. If this is the case, we could run the server directly out of /vagrant instead of /var/www/karmaworld, but that breaks some amount of staging and production duplication that we'd like to see on the dev systems.

[btbonval]

Weird. /vagrant/ is a different file system, but I was able to soft link it across file systems. Maybe hard links can't go across file systems but soft links can. At any rate, this should be an easy fix.

[btbonval]

well junk. For the most part, this all works fine, but there's one snaggle with the /vagrant directory in VirtualBox which is noted by two answers on this Stackoverflow question: http://stackoverflow.com/questions/11265091/virtualenv-not-creating-an-environment

No real answer. The workaround is to create the virtualenv elsewhere, but that breaks the synchronicity with staging/prod systems.

Here's a workaround. If it works, I should call back to the SO question and add it: http://ahtik.com/blog/fixing-your-virtualbox-shared-folder-symlink-error/

[btbonval]

sweet. workaround. batman!

[btbonval]

Got through the whole setup up through the last step, then BAM new problem. Because life.

[127.0.0.1] run: supervisord -c /var/www/karmaworld/confs/prod/supervisord.conf
[127.0.0.1] out: Error: Cannot open an HTTP server: socket.error reported errno.EPERM (1)
[127.0.0.1] out: For help, use /var/www/karmaworld/venv/bin/supervisord -h
[127.0.0.1] out:

Operation not permitted.

I'm guessing its all this /var/www/karmaworld/var/... stuff, which drops sockets and all kinds of nonsense on the file system. Since this file system is a bit restrictive and not part of the VM really, I'm not surprised this breaks. YAY!

I never did like having all that var stuff jammed into the project directory like that. Oh well, staging and production do it, so the VM must as well.

I could softlink /var/www/karmaworld/var somewhere else on the VM. That might fix the issue, but then the host machine has this crazy var softlink which will be nonsensical. I'm beginning to question how much I care to complete this operation.

[btbonval]

Alright, well this is the time when we all agree that sunk costs are indeed a fallacy. The time I've spent working on this was a nice experiment, but ultimately this cannot be done with the current setup of staging and prod.

I'm closing this ticket as won't fix. Sometime in the future, after staging/prod move the var junk somewhere more appropriate, this can be tried again.

[btbonval]

Future reference, should the day ever come to pass, Vagrantfile diff:

@@ -60,13 +60,11 @@ mkdir -m 775 -p /var/www
 chown -R :www-data /var/www
 usermod -a -G www-data vagrant

-su vagrant -c "git clone /vagrant karmaworld"
+ln -s /vagrant /var/www/karmaworld

-SECRETPATH="karmaworld/secret"
+SECRETPATH="/var/www/karmaworld/karmaworld/secret"

-su vagrant -c "cp /vagrant/$SECRETPATH/* karmaworld/$SECRETPATH/"
-
-CFILE="karmaworld/$SECRETPATH/db_settings.py"
+CFILE="$SECRETPATH/db_settings.py"
 cat > $CFILE <<CONFIG
 #!/usr/bin/env python
 # -*- coding:utf8 -*-
@@ -78,7 +76,7 @@ PROD_DB_NAME = 'karmaworld'
 PROD_DB_USERNAME = 'vagrant'
 PROD_DB_PASSWORD = ''
 CONFIG
-chown vagrant:vagrant karmaworld/$SECRETPATH/*.py
+chown vagrant:vagrant $SECRETPATH/db_settings.py

Farewell diff, we knew you half as well as we ought to and liked you twice as much as you deserved.