--------------------------------------------------------------
Migration Plan

BLAST II Database

Dennis Box, Michelle McCusker-Whiting

Mar 24, 2005


INTRODUCTION:

A database containing magnet properties and position data has
been developed by Fermilab Computing Division (CD) as part of
the BLAST project.  The goal of the BLAST project is assisting
the Accelerator Division (AD) in modeling magnet/particle
accelerator behavior.

The database and its web interface were prototyped using Sybase
and PostgreSQL databases, an Apache web server and the php
programming language with graphics and database access libraries.
All of this software except for the Sybase database is currently
running on linux desktop odets3.fnal.gov in Dennis Box's office.
This system needs to be moved from the prototype into a production
environment where it can be administered by AD personnel.

We propose to accomplish this migration via the following steps:



STEP 0
  Task: Schema/application acceptance
  Personnel: Dennis Box, Norm Gelfand, AD Stakeholders
  Timeline: next few weeks

    1) Presentation of  schema/application to stakeholders
    2) Changes that can be made quickly will be made and the source
      code checked into cvs.  More complicated change requests
      will be documented as well as possible and implemented
      after the migration.


STEP 1
  Task:AD server(s) architecture decisions
  Personnel: AD (assigned by Francois?)
  Timeline: can proceed in parallel with STEP 0

     To accomplish this step, some hardware/architectural
     decisions need to be made.  The prototype runs adequately
     on odets3, a 500Mhz Pentium III class linux machine with
     512 M of RAM , 30 G of disk and a generic 10Base-T ethernet
     card.  It is not envisioned that the BLAST system will have
     to support more than a few connections per second.
     Nightly database backups currently go to disk, then to /pnfs
     when a change from the previous backup is detected. It is
     recommended to change this aspect of the backup plan to go
     to some other backup system owned by AD.


     A possible architecture:

     The BLAST II database will run on two dedicated linux machines
     of at least pentium III class, one designated production,
     one development.  Each machine will run a PostgreSQL database
     server, an Apache web server, and php with associated libraries.
     Database backups will be performed to disk and then to tape over
     the network, data maintenance will be performed through a
     combination of web forms and scripts run at the sql prompt.
     Data browsing pages will be open to the entire internet, data
     maintenance web pages and scripts will only be accessible from
     behind the AD firewall.


     An alternative:

     Production machine as above, but development environment remains
     odets3.  Among the disadvantages of this approach are:

     -AD developers need logins/access to Dennis' machine.
     -The development and production environment will be more likely
      to be different in unexpected ways. -odets3 is old, getting
      flaky (a power supply died last month causing a small panic),
      and no regular backups are performed other than cvs of
      application code and database backups.


STEP 2
  Task:Base Software Install
  Personnel: Michele McCusker-Whiting
  Timeline: STEP 1 + 3-4 days.  Michelle has practiced
            most parts of it for the BLAST phase I install.
            Install and configure the following packages on
            the target machine:

            -PostgreSQL  7.4.1
            -Apache/1.3.29
            -PHP 4.3.4
            -adodb 4.0.4 (php database access layer)
            -jpgraph 1.15 (php graphics layer)

            Also:
            -add user dbox to machine(s)

STEP 3
    Task:Data/Application Install
    Personnel: Michele McCusker-Whiting, Dennis Box
    Timeline: STEP 2 + 3-4 days.

     1) obtain cvs access to cdcvs.fnal.gov from behind
        AD firewall (done?)
     2) cvs checkout of php application code
     3) load postgres database from current nightly backups
     4) tweak the database server/web server/application code
        until it all works together. Again, Michele has done
        this on the phase I database .


STEP 4
  Task:Acceptance Testing
  Personnel: Norman Gelfand, Dennis Box, Michele McCusker-Whiting
             (others?)
  Timeline: STEP 3 + 10 days

      1)Verify that casual users can browse database
      2)Verify that data maintainer(s) can  move magnets,
        add magnet comments, add survey data using web interface
      3)Check that backup/restore works for database dumps and cvs
        application code.
      4)Make changes to database/application that were noted
        in STEP 0 but not implemented.


STEP 5
  Task: Decommisioning of odets3 server
  Personnel: Dennis Box
  Timeline : STEP 4 + 5 minutes if development environment is
             not odets3 otherwise STEP 4 + infinity.