[Bio] / FigCommon / ConfigNotes Repository:
ViewVC logotype

Annotation of /FigCommon/ConfigNotes

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.2 - (view) (download)

1 : olson 1.1 SEED Configuration Notes
2 :     ========================
3 :     Robert Olson <olson@mcs.anl.gov>
4 :     Dec 2003
5 :    
6 :     Following are some notes on SEED configuration and bootstrapping issues.
7 :    
8 : olson 1.2 Configuration Flow
9 :     ------------------
10 :    
11 :     We examine this from the point of view of a user who has just
12 :     downloaded a new SEED instance.
13 :    
14 :     Unpacking
15 :     ~~~~~~~~~
16 :    
17 :     First, the bundled SEED is unpacked into a directory. This might look
18 :     like this:
19 :    
20 :     ---
21 :     bash-2.05a$ cd DVD-Tues/
22 :     bash-2.05a$ ls -l
23 :     total 24623064
24 :     -rw-r--r-- 1 fig staff 4000000000 Dec 9 10:26 0
25 :     -rw-r--r-- 1 fig staff 4000000000 Dec 6 17:32 1
26 :     -rw-r--r-- 1 fig staff 4000000000 Dec 6 18:20 2
27 :     -rw-r--r-- 1 fig staff 606970786 Dec 9 10:14 3
28 :     -rwxr-xr-x 1 fig staff 311 Dec 9 13:28 ConfigureDB.command
29 :     -rwxr-xr-x 1 fig staff 115 Dec 9 13:22 ConfigureSEED.command
30 :     -rwxr-xr-x 1 fig staff 1801 Dec 9 13:18 Install.command
31 :     -rw-r--r-- 1 fig staff 33 Dec 10 06:35 LoadDB.command
32 :     -rwxr-xr-x 1 fig staff 5001 Dec 9 15:23 README
33 :     -rw-r--r-- 1 fig staff 94 Dec 9 11:03 checksums
34 :     bash-2.05a$ cat checksums
35 :     751136637 4000000000 0
36 :     1063888525 4000000000 1
37 :     4122583065 4000000000 2
38 :     4139105322 606970786 3
39 :     ---
40 :    
41 :     A bootstrapping program (including the .command files up there)
42 :     inflates the compressed and split parts of the SEED installation to a
43 :     destination directory.
44 :    
45 :     Configuration
46 :     ~~~~~~~~~~~~~
47 :    
48 :     Now the user invokes a single command, configure, found at the
49 :     toplevel of the SEED instance. It takes a single argument that is the
50 :     name of the execution environment we're configuring for.
51 :    
52 :     It creates the following files:
53 :    
54 :     config/tool_hdr
55 :     config/tool_hdr_py
56 :     config/fig-user-env.sh
57 :     config/fig-user-env.csh
58 :     config/FIG_Config.pm
59 :     config/FIG_Config.py
60 :    
61 :     After that setup is complete, a new shell is started (to load up the
62 :     newly-computed environment), and a switch_to_release is performed.
63 :    
64 :     switch_to_release
65 :     ~~~~~~~~~~~~~~~~~
66 :    
67 :     The switch_to_release program causes a particular code release to be
68 :     made the current release. This currently involves:
69 :    
70 :     ---
71 :     # Check to be sure that $fig_disk/dist/releases/<release_number> exists
72 :     # Update $fig_disk/CURRENT_RELEASE with the new release number.
73 :     # Swing the symlinks $fig_disk/FIG/bin and $fig_disk/FIG/CGI to the right place
74 :     ---
75 :    
76 : olson 1.1 Instance Identification
77 :     -----------------------
78 :    
79 :     For a number of reasons, we would like to have each SEED instance
80 :     tagged with a unique identifier. These reasons include
81 :    
82 :     - Tracing the heritage of peer-to-peer updates to the SEED data.
83 :    
84 :     - Uniquely identifying SEED peers in a peer registry.
85 :    
86 :     The key problem I am facing in generating this identification is the
87 :     mechanism by which it is stored, and the interaction of that mechanism
88 :     with copying SEED disks.
89 :    
90 :     The straightforward way - saving it in a flat file at the top of the
91 :     SEED disk - will cause replication of the unique identifier if a SEED
92 :     disk is copied to a new computer.
93 :    
94 :     I don't want to just create a new identifier each time the SEED
95 :     configuration script is executed, since it should be legal to run that
96 :     script any number of times; a given SEED instance should always have
97 :     the same identifier.
98 :    
99 :     I think a sufficient solution for now would be to require that the
100 :     identifier file be deleted when a SEED instance is copied. This is a
101 :     policy that could be enforced by a "seed_export" mechanism that
102 :     formalizes the process of duplicating a SEED instance.
103 :    
104 :     ID file format
105 :     ~~~~~~~~~~~~~~
106 :    
107 :     ---
108 :     id <UUID string>
109 :     created-on <hostname>
110 :     created-by <username>
111 :     creation-date <date>
112 :     ---
113 :    
114 :     Postgres Database Cluster
115 :     -------------------------
116 :    
117 :     The postgres database server requires a "data directory" in order to
118 :     run. The Postgres folks call this a "database cluster", and it holds
119 :     all the data required for a single database process (listening on a
120 :     given TCP port). A database cluster can hold multiple databases.
121 :    
122 :     We need to ensure that we have a database cluster for running the SEED
123 :     instance. We don't necessarily need to have a database cluster per
124 :     SEED instance, but it may be useful to do so in order to ensure
125 :     encapsulation - we assume currently that each seed instance uses its
126 :     own database process, started and stopped by the start-servers and
127 :     stop-servers scripts.
128 :    
129 :     NOTE: we can change this behavior sometime in the future; in fact it
130 :     might be a useful thing to do if we want things to be available at
131 :     boot.
132 :    
133 :     We need to bind the database cluster directory to the directory that
134 :     we're installing the SEED instance in. We need to also uniquely
135 :     identify the directory the SEED instance is in in order to create a
136 :     unique database cluster directory for this instance. We do this by
137 :     using the inode number of the toplevel of the SEED directory as a key
138 :     (this will not work on Windows; however, on Windows, we can use the
139 :     pathname as the basis for this, as there are no symlinks in Windows).
140 :    
141 :     We go through this hoop in order to maintain the property that the
142 :     configuration can be done repeatedly without repeatedly recreating the
143 :     database cluster and wiping out data that doesn't need to be wiped
144 :     out.
145 :    
146 :     The cluster directory itself is created in the FIGdb directory in the
147 :     home directory of the current user. An index file is kept there to
148 :     serve as a human-readable directory to the clusters that have been
149 :     created. It looks like this:
150 :    
151 :    
152 :    
153 :     ---
154 :     Database cluster index
155 :    
156 :     Cluster dir FIG dir Ident
157 :     /Users/fig/FIGdb/1 /Users/fig/FIGDisk.internal/FIGdisk inode=63934
158 :     ---
159 : olson 1.2
160 : olson 1.1
161 :    

MCS Webmaster
ViewVC Help
Powered by ViewVC 1.0.3