1. Where everything is

• The source code for the openshift enabled version of Planeteria is found at https://github.com/owtaylor/planeteria - we should probably set up an organization and move the source code there, so it can be hacked on in a shared fashion. (Alternatively, whoever is working on planeteria.info can deploy from their personal repository, but that will make it confusing what’s the latest ersion.) The source code is also checked into a git repository as part of openshift, but that should be considered a deployment thing, and not where the code is maintained.

• http://www.planeteria.info is hosted on an openshift “gear” - I should be able to add additional openshift users into the domain who will be able to deploy new versions and maintain the code as well.

• http://planeteria.info is a redirect to http://www.planeteria.info hosted on the server that I use for fishsoup.net - it shouldn’t need any maintanance, except if we want to set up a similar bounce for https://planeteria.info (see https item below)

• The DNS for planeteria.info is hosted with the registrar PairNIC - contact me if you need any changes.

2. Setting up a Planeteria instance in OpenShift

• Create an account on openshift
• Install the ‘rhc’ command line tool

• Run ‘rhc setup’; among other things this will prompt you for the name of the initial domain for your account; something like a username probably makes most sense - this will be used for URLs of the form <appname>-<domain>.rhcloud.com

• Now create the app, and configure it

rhc app create --from-code https://github.com/owtaylor/Planeteria.git
 planeteria python-2.7 # ‘planeteria’ here is the app name
rhc cartridge add cron-1.4 -a planeteria
rhc ssh -a planeteria
<in the partition>
cd app-root/data
echo http://planeteria-<mydomain>.rhcloud.com > base_href

3. Using a custom name for a Planeteria instance

• Put the right name into app-root/data/base_href as above
• On your local machine, run ‘rhc alias add planeteria www.planeteria.info’

4. To Do

4.1. Static content

The OpenShift Python setup (the Python “cartridge”) is quite limited in its handling of static content - all static content must live in the application in the wsgi/static directory and be served with an URL of static/. For this reason, the static data is currently not served statically at all, but rather is served by the WSGI handler. The downsides of this are:

• A decrease in efficiency, since the files are being served by Python rather than the core Apache code.
• Since in the current code for static files in wsgi.py there is no handling for modification times, or etags, and the corresponding If-Match/If-Modified headers for requests, meaning that web browsers will frequently request and receive in full static resources that don’t change.

Approaches to improving things here:

• A powerful technique for static data is, instead of referring to a static resource, as say, pub.d/css/planteria.css, refer to it as pub.d/<build_id>/planeteria.css - this can be done in template expansion. Then when handling a request for static content in wsgi.py, the build id can be stripped and an “infinite” expiration time set far in the future.

• Move real static data (css, images, etc) into the locations that are expected - wsgi/static and static/ … though this will get Apache serving these files, the first approach is actually more powerful in terms of reducing web traffic and reducing bandwidth.
• Implement handling of the modification time, etc, HTTP headers.

• Switch to a web framework (perhaps CherryPy) that itself has better handling of static files.

• Have two openshift applications - one of which uses, say, Varnish, to cache the output of the other one.

I think the first approach is probably sufficient on its own, unless the traffic level gets very high.

4.2. Templates and structure

• Update information to match the current deployment - should the donation button still be there? Links to different planets from the front page need to be cleaned up?
• Is the ability to create new planets actually needed, or should it be disabled/hidden for this deployment?

4.3. Cleanups

• config handling seems completely inconsistent in whether config.* or config.opt.* is used.
• In new_planet.py and admin.py rather add-hoc parameters are passed around to different functions. Having Request and Response objects that have form data, paths, error accumulation, etc, functionality, would make things more readable.

4.4. Misc

• Change the updates request form based on the new planet name

• Change the address for sending updates to (wfsplanet@googlegroups.com) based on the new planet name

4.5. https

As a general principle, all form submissions should be over https, so having new_planet.py and admin.py be unencrypted is somewhat bad. It’s probably best to just make the entire site https based - this is automatically available with openshift if you access things through the standard <appname>-<domain>.rhcloud.com, but will require getting a SSL certificate to make it work has https://www.planeteria.info.