Not logged in - Log In / Register

Note: this may be out of date. Someone with knowledge needs to review.

Launchpad Staging Server(s)


We have a 'staging' launchpad server on and Librarian on It is running on the server asuka.


It is being rebuilt every day:

  1. At 00:10 UTC, emperor backs up its databases.
  2. When this is done (approximatly 00:25 UTC) is shutdown.
  3. The launchpad_staging database is then destroyed and restored from the newly created backup of the production launchpad database.
  4. A fresh copy of chinstrap:/home/warthogs/archives/rocketfuel-build/launchpad is made
  5. The database upgrade scripts are run to ensure the database schema patch level matches the requirements of the code patch level.
  6. The server is then restarted.

Instructions for doing a manual update are on StagingServerUpdate.

The output of this process is currently being emailed to Select the PostgreSQL topic to receive them.

Differences from production environment

  1. There is a special robots.txt file installed so the staging server does not get googled.
  2. No cron scripts are currently being run.


  1. Seperate the staging rebuild reports from the PostgreSQL ones and create a new launchpad-error-reports topic filter.
  2. cron scripts. We need to ensure they don't try to run during upgrades. We also need a single script to be run by con every 60 seconds instead of adding each one to cron individually (which will be a source of rollout errors).

Experimental vs. Staging

Currently staging is misnamed, as it is running bleeding edge code. We really need two servers - and Experimental will run bleeding edge code, and we may be able to allow developers to roll out branches that are not yet in rocketfuel. staging will be used for testing the next version for release. Most likely the process will be:

  1. On Monday, the existing branch is rolled out to production.

  2. On Monday, is tagged as the new staging branch. This is rolled out to

  3. During the week, fixes are merged into the current staging branch to fix errors identified on the staging server.

This process means that new features will not land on production for at least 1 week. However, bugs identified on the staging server can be fixed. We have regular, scheduled, production updates.

StagingServer (last edited 2009-11-30 17:18:17 by gary)