[Bio] / FigCommon / ConfigNotes Repository:
ViewVC logotype

View of /FigCommon/ConfigNotes

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.2 - (download) (annotate)
Tue Dec 23 16:10:48 2003 UTC (15 years, 10 months ago) by olson
Branch: MAIN
CVS Tags: mgrast_dev_08112011, rast_rel_2009_05_18, mgrast_dev_08022011, rast_rel_2014_0912, rast_rel_2008_06_18, rast_rel_2008_06_16, mgrast_dev_05262011, merge-trunktag-bobdev_news-2, rast_rel_2008_12_18, mgrast_dev_04082011, rast_rel_2008_07_21, rast_rel_2010_0928, rast_2008_0924, mgrast_version_3_2, mgrast_dev_12152011, Root-bobdev_news, rast_rel_2008_04_23, merge-bobdev_news-1, help, mgrast_dev_06072011, rast_rel_2008_09_30, rast_rel_2009_0925, rast_rel_2010_0526, rast_rel_2014_0729, merge-trunktag-bobdev_news-1, mgrast_dev_02212011, rast_rel_2010_1206, caBIG-05Apr06-00, mgrast_release_3_0, mgrast_dev_03252011, rast_rel_2010_0118, mgrast_rel_2008_0924, mgrast_rel_2008_1110_v2, rast_rel_2009_02_05, rast_rel_2011_0119, merge-bodev_news-3, lwc, mgrast_rel_2008_0625, mgrast_release_3_0_4, mgrast_release_3_0_2, mgrast_release_3_0_3, mgrast_release_3_0_1, mgrast_dev_03312011, caBIG-00-00-00, mgrast_release_3_1_2, mgrast_release_3_1_1, mgrast_release_3_1_0, merge-bobdev_news-2, mgrast_dev_04132011, rast_rel_2008_10_09, mgrast_dev_04012011, rast_release_2008_09_29, mgrast_rel_2008_0806, mgrast_rel_2008_0923, mgrast_rel_2008_0919, rast_rel_2009_07_09, rast_rel_2010_0827, mgrast_rel_2008_1110, myrast_33, rast_rel_2011_0928, rast_rel_2008_09_29, mgrast_rel_2008_0917, rast_rel_2008_10_29, mgrast_dev_04052011, mgrast_dev_02222011, caBIG-13Feb06-00, rast_rel_2009_03_26, mgrast_dev_10262011, rast_rel_2008_11_24, rast_rel_2008_08_07, merge-trunktag-bodev_news-3, HEAD
Branch point for: Branch-bobdev_news
Changes since 1.1: +69 -0 lines
More configure setup.

SEED Configuration Notes
========================
Robert Olson <olson@mcs.anl.gov>
Dec 2003

Following are some notes on SEED configuration and bootstrapping issues.

Configuration Flow
------------------

We examine this from the point of view of a user who has just
downloaded a new SEED instance.

Unpacking
~~~~~~~~~

First, the bundled SEED is unpacked into a directory. This might look
like this:

---
bash-2.05a$ cd DVD-Tues/
bash-2.05a$ ls -l
total 24623064
-rw-r--r--  1 fig  staff  4000000000 Dec  9 10:26 0
-rw-r--r--  1 fig  staff  4000000000 Dec  6 17:32 1
-rw-r--r--  1 fig  staff  4000000000 Dec  6 18:20 2
-rw-r--r--  1 fig  staff   606970786 Dec  9 10:14 3
-rwxr-xr-x  1 fig  staff         311 Dec  9 13:28 ConfigureDB.command
-rwxr-xr-x  1 fig  staff         115 Dec  9 13:22 ConfigureSEED.command
-rwxr-xr-x  1 fig  staff        1801 Dec  9 13:18 Install.command
-rw-r--r--  1 fig  staff          33 Dec 10 06:35 LoadDB.command
-rwxr-xr-x  1 fig  staff        5001 Dec  9 15:23 README
-rw-r--r--  1 fig  staff          94 Dec  9 11:03 checksums
bash-2.05a$ cat checksums 
751136637 4000000000 0
1063888525 4000000000 1
4122583065 4000000000 2
4139105322 606970786 3
---

A bootstrapping program (including the .command files up there)
inflates the compressed and split parts of the SEED installation to a
destination directory.

Configuration
~~~~~~~~~~~~~

Now the user invokes a single command, configure, found at the
toplevel of the SEED instance. It takes a single argument that is the
name of the execution environment we're configuring for.

It creates the following files:

   config/tool_hdr
   config/tool_hdr_py
   config/fig-user-env.sh
   config/fig-user-env.csh
   config/FIG_Config.pm
   config/FIG_Config.py

After that setup is complete, a new shell is started (to load up the
newly-computed environment), and a switch_to_release is performed.

switch_to_release
~~~~~~~~~~~~~~~~~

The switch_to_release program causes a particular code release to be
made the current release.  This currently involves:

---
# Check to be sure that $fig_disk/dist/releases/<release_number> exists
# Update $fig_disk/CURRENT_RELEASE with the new release number.
# Swing the symlinks $fig_disk/FIG/bin and $fig_disk/FIG/CGI to the right place
---

Instance Identification
-----------------------

For a number of reasons, we would like to have each SEED instance
tagged with a unique identifier. These reasons include 

- Tracing the heritage of peer-to-peer updates to the SEED data.

- Uniquely identifying SEED peers in a peer registry.

The key problem I am facing in generating this identification is the
mechanism by which it is stored, and the interaction of that mechanism
with copying SEED disks.

The straightforward way - saving it in a flat file at the top of the
SEED disk - will cause replication of the unique identifier if a SEED
disk is copied to a new computer.

I don't want to just create a new identifier each time the SEED
configuration script is executed, since it should be legal to run that
script any number of times; a given SEED instance should always have
the same identifier. 

I think a sufficient solution for now would be to require that the
identifier file be deleted when a SEED instance is copied. This is a
policy that could be enforced by a "seed_export" mechanism that
formalizes the process of duplicating a SEED instance.

ID file format
~~~~~~~~~~~~~~

---
id <UUID string>
created-on <hostname>
created-by <username> 
creation-date <date>
---

Postgres Database Cluster
-------------------------

The postgres database server requires a "data directory" in order to
run. The Postgres folks call this a "database cluster", and it holds
all the data required for a single database process (listening on a
given TCP port). A database cluster can hold multiple databases.

We need to ensure that we have a database cluster for running the SEED
instance. We don't necessarily need to have a database cluster per
SEED instance, but it may be useful to do so in order to ensure
encapsulation - we assume currently that each seed instance uses its
own database process, started and stopped by the start-servers and
stop-servers scripts. 

NOTE: we can change this behavior sometime in the  future; in fact it
might be a useful thing to do if we want things to be available at
boot. 

We need to bind the database cluster directory to the directory that
we're installing the SEED instance in. We need to also uniquely
identify the directory the SEED instance is in in order to create a
unique database cluster directory for this instance. We do this by
using the inode number of the toplevel of the SEED directory as a key
(this will not work on Windows; however, on Windows, we can use the
pathname as the basis for this, as there are no symlinks in Windows).

We go through this hoop in order to maintain the property that the
configuration can be done repeatedly without repeatedly recreating the
database cluster and wiping out data that doesn't need to be wiped
out.

The cluster directory itself is created in the FIGdb directory in the
home directory of the current user. An index file is kept there to
serve as a human-readable directory to the clusters that have been
created. It looks like this:



---
Database cluster index

Cluster dir		FIG dir					Ident
/Users/fig/FIGdb/1	/Users/fig/FIGDisk.internal/FIGdisk	inode=63934
---




MCS Webmaster
ViewVC Help
Powered by ViewVC 1.0.3