Infrastructure Priorities
Not necessarily in order of priority...but priorities nonetheless
- Update/add to infrastructure documentation on wiki (there is a lot of outdated info)
- Document slony/data replication, or investigate other options if slony doesn't meet our needs
- Backup of the git repo
- Backup of the live DB server (will require slony configuration)
- Compare costs of datapipe vs Amazon
- What is state of offsite backups? If these are being done, where? If not, investigate solutions (tape most likely)
- Need to complete workstation/server images (these are about 90% complete)
- What is status of nagios?
- Poprocks: /var/lib/pgsql is running out of room. Need to fix pgsql logging, maybe turn job over to logrotate so we can compress and rotate them more efficiently.
- Refactoring of pypvs:
(11:22:28 AM) brian: how difficult would it be to write regression tests against pypvs? (11:22:57 AM) brian: I'm thinking something like calling the different django routines, looking at the results, etc. (11:23:02 AM) adrian: like system wide testing? (11:23:11 AM) brian: yeah (11:24:18 AM) brian: I bet there's already a django testing framework out there... (11:24:19 AM) adrian: it'd probably take awhile (11:24:27 AM) brian: oh no doubt (11:25:17 AM) adrian: that's the kind of thing where it might be smarter to start looking at upgrading to python 3 and refactoring modules along the way, writing tests as we go (11:25:51 AM) brian: yeah, that's a good approach (11:27:08 AM) adrian: I've got some ideas for what a refactored pypvs should look like (11:27:49 AM) adrian: the biggest thing would be to not have the project itself in the master branch (11:28:19 AM) adrian: only publishing the modules makes it waaay easier to deploy/set up in development (11:28:39 AM) brian: that's how it's usually done with django apps? (11:28:44 AM) adrian: yah (11:28:54 AM) brian: the modules are basically independent of one another? (11:28:58 AM) adrian: yes (11:29:19 AM) brian: so they don't share the same settings.py, urls.py, etc. files? (11:29:33 AM) adrian: they do (11:29:40 AM) adrian: you just organize it differently (11:29:41 AM) adrian: so (11:29:49 AM) adrian: you set up your local project folder (11:29:58 AM) adrian: and then import the urls from the modules you want (11:30:33 AM) adrian: it promotes a higher degree of orthogonality (11:30:46 AM) adrian: which is important in a big project (11:31:05 AM) brian: oh I'm a big fan of low coupling :) (11:31:16 AM) adrian: ha, me too (11:31:30 AM) adrian: so right now, all the urls are in pypvs/urls.py (11:31:54 AM) brian: sort of like a dispatcher (11:31:58 AM) adrian: this is no good, because what if the 'keyvotes' module doesn't load/dissappears/etc ? (11:32:01 AM) adrian: yah (11:32:46 AM) adrian: so a cleaner way to do it would have a urls file in the keyvotes modules that imports into the home urls file (11:34:07 AM) adrian: And I'd like to run this one by Mike as well, but there are more modern ways to set up your django server (11:34:39 AM) brian: good points...we should probably dump some of these ideas on the wiki (11:34:43 AM) adrian: maybe use a framework like twisted or tornado to set up non-blocking servers (11:34:48 AM) adrian: yah (11:35:17 AM) adrian: when pypvs was started, the web was a different place. blocking WSGI processes were the norm. (11:35:27 AM) adrian: but we've got a data-heavy app (11:35:42 AM) adrian: so setting up some non-blocking io could prove beneficial (11:35:44 AM) adrian: plus (11:35:55 AM) adrian: it's more efficient in terms of server load
CategoryITDefunct