For IMP developers
Note that this document refers to the IMP deployment on flipendo. It is specific to this instance, and is not a general imp deployment guide.
Development should be carried out in the imp-dev instance located at
This instance of IMP has it's own database (the development database). It is therefore acceptable to run migrations on imp-dev. When creating migrations, insure that any delete operations on the database (removing tables, columns, etc.) are the final database changes before moving to imp-stage, and that they are not encompassed in any required migrations (i.e. adding columns, tables, etc). IMP dev is served at http://imp-dev.princeton.edu. In terms of settings, imp-dev should usually have DEBUG=True.
Moving changes to production
The 'www' directories in each of these are symlinks to either imp-dog or imp-cat. Whichever of these is pointed to by imp/www will be served at imp.princeton.edu.
To update the code running on the public imp server without downtime, go to the staging instance. Pull changes, and run any database migrations THAT DO NOT DELETE TABLES OR COLUMNS. Test this webserver through http://imp-stage.princeton.edu. When you are satisfied with the situation, change the symlink at /Genomics/local/imp/www to point to the newly updated imp code (imp-dog or imp-cat), and change the symlink at /Genomics/local/imp-stage/www to point to the other directory. Once the new code is live at http://imp.princeton.edu, database migrations can be run that delete tables or columns.
Please note that in imp-dog and imp-cat should never be deployed publicly (to http://imp.princeton.edu) with DEBUG=True set. If you do need to work on imp-stage with debug, make sure you turn it off before switching it to the production (imp) instance.
Clearing the Cache
imp-dog and imp-cat each add separate keys to the cache. This means that switching imp-stage and imp should be enough to make new templates, etc, live. Everything is cached for 24 hours (unless the cache fills up) so as long as imp-dog and imp-cat aren't switched more frequently than that, there should not be an issue. In the case that someone does wish to clear the cache, run
source imppy/bin/activate python manage.py shell
to get a django shell. Then inside the shell run
from django.core.cache import cache cache.clear()
Setting up virtualenv
mkdir imppy virtualenv --no-site-packages imppy source imppy/bin/activate # Current hack for haystack beta pip install -e git://github.com/toastdriven/django-haystack.git@master#egg=django-haystack pip install -r requirements.txt