Difference between revisions of "Monk upgrade"

From HaskellWiki
Jump to: navigation, search
m (MonkUpgrade moved to Monk upgrade)
 
(4 intermediate revisions by 3 users not shown)
Line 12: Line 12:
 
# Wider post-upgrade testing and observations
 
# Wider post-upgrade testing and observations
   
== Application Upgrades ==
+
== Application upgrades ==
   
 
Which crucial applications will be upgraded?
 
Which crucial applications will be upgraded?
Line 20: Line 20:
 
MySQL, PostgreSQL, SQLite, BerkeleyDB -- which of them are in active use and candidates for upgrades? Their data stores will likely need a dump and restore...
 
MySQL, PostgreSQL, SQLite, BerkeleyDB -- which of them are in active use and candidates for upgrades? Their data stores will likely need a dump and restore...
   
== Downtime Plan ==
+
=== Apache ===
  +
Migration to version 2. Need to update server config, and .htaccess files.
  +
  +
Start using mod_python? --SimonM
  +
  +
=== MySQL ===
  +
Nobody claimed to be using this.
  +
  +
As root, in /root, run
  +
<pre>mysqldump --all-databases &gt; backup-mysql-db-4.0.24-sarge-`date +%F`</pre>
  +
before doing the upgrade. Then upgrade mysql and stop the server running to see if anyone complains.
  +
  +
=== PostreSQL ===
  +
Nobody claimed to be using this.
  +
  +
As the postgres user, in its home directory /srv/postgres,run
  +
<pre>pg_dumpall &gt; backup-db-7.4.7-sarge-`date +%F`</pre>
  +
before doing the upgrade. Then upgrade postgres (it should migrate the data) and stop the server running to see if anyone complains.
  +
  +
=== SQLite ===
  +
Used by Trac. To upgrade the databases, do this for each trac instance foo:
  +
  +
<pre>
  +
cd /srv/trac/foo/db
  +
mv trac.db trac2.db
  +
sqlite trac2.db .dump | sqlite3 trac.db
  +
trac-admin /srv/trac/foo upgrade
  +
comment out repository_type and repository_dir in ../conf/trac.ini
  +
</pre>
  +
  +
=== CVS ===
  +
Paul offerred to deal with this one.
  +
  +
=== Trac ===
  +
It should be possible to upgrade Trac independently after the upgrade. If so, I think we should do that, in order to reduce dependencies and shorten the downtime.
  +
  +
=== Darcs ===
  +
No upgrade required: we don't use the Debian-supplied version here.
  +
  +
== Downtime plan ==
   
 
The downtime plan in as much detail as possible.
 
The downtime plan in as much detail as possible.
   
Schedule...
 
  +
We need to move /home to the /srv partition, as it is running out of space.
  +
 
===Schedule===
  +
  +
===Regression tests===
 
Preferably scripted, with "owner" who decides how to proceed in event of failure.
   
Regression tests -- preferably scripted, with "owner" who decides how to proceed in event of failure.
 
  +
Verify that we can
  +
* use darcs, including remote push
  +
* send external email (including darcs reports)
  +
* use all the Tracs
  +
* use darcsweb
  +
* use Hackage
  +
* use CVS
   
Rollback plan(s)
+
===Rollback plan(s)===
   
== Post-Upgrade Notes and Observations ==
+
== Post-upgrade notes and observations ==
   
 
Anything we learned or observed that will be helpful as we move forward?
 
Anything we learned or observed that will be helpful as we move forward?

Latest revision as of 17:13, 1 July 2007

cvs.haskell.org (aka haskell.galois.com; aka monk) is in need of an OS upgrade. It's currently running Debian sarge; the upgrade will be to etch, the current stable version of Debian.

This page is meant to host discussion of

  1. Which crucial applications will be upgraded (with specific version numbers)?
    1. What config files will need tweaking?
    2. What binary data stores (e.g., database disk files) will need processing?
  2. The downtime plan
    1. Schedule
    2. Regression tests (including who will carry them out)
    3. Rollback plan(s)
  3. Wider post-upgrade testing and observations

Application upgrades

Which crucial applications will be upgraded?

Notes on re-configuration...

MySQL, PostgreSQL, SQLite, BerkeleyDB -- which of them are in active use and candidates for upgrades? Their data stores will likely need a dump and restore...

Apache

Migration to version 2. Need to update server config, and .htaccess files.

Start using mod_python? --SimonM

MySQL

Nobody claimed to be using this.

As root, in /root, run

mysqldump --all-databases > backup-mysql-db-4.0.24-sarge-`date +%F`

before doing the upgrade. Then upgrade mysql and stop the server running to see if anyone complains.

PostreSQL

Nobody claimed to be using this.

As the postgres user, in its home directory /srv/postgres,run

pg_dumpall > backup-db-7.4.7-sarge-`date +%F`

before doing the upgrade. Then upgrade postgres (it should migrate the data) and stop the server running to see if anyone complains.

SQLite

Used by Trac. To upgrade the databases, do this for each trac instance foo:

cd /srv/trac/foo/db
mv trac.db trac2.db
sqlite trac2.db .dump | sqlite3 trac.db
trac-admin /srv/trac/foo upgrade
comment out repository_type and repository_dir in ../conf/trac.ini

CVS

Paul offerred to deal with this one.

Trac

It should be possible to upgrade Trac independently after the upgrade. If so, I think we should do that, in order to reduce dependencies and shorten the downtime.

Darcs

No upgrade required: we don't use the Debian-supplied version here.

Downtime plan

The downtime plan in as much detail as possible.

We need to move /home to the /srv partition, as it is running out of space.

Schedule

Regression tests

Preferably scripted, with "owner" who decides how to proceed in event of failure.

Verify that we can

  • use darcs, including remote push
  • send external email (including darcs reports)
  • use all the Tracs
  • use darcsweb
  • use Hackage
  • use CVS

Rollback plan(s)

Post-upgrade notes and observations

Anything we learned or observed that will be helpful as we move forward?

Heinlein 19:04, 25 June 2007 (UTC)