Changes between Version 3 and Version 4 of VYSOS5.20091011

Timestamp:

Oct 21, 2009, 5:50:34 PM (17 years ago)

Author:

eugene

Comment:

--

VYSOS5.20091011

@@ -54 +54 @@
 }}}
 
+I initially attempted to run the pantasks and the processing on vysosdata1, which also is the data host and the mysql host.  This was not very successful.  The load on vysosdata1 was too large and the database interactions very quickly timed out, causing various failures.
 
+To address this, I've had to set up the processing on the IPP fruitbowl in Hilo.  This took a big of work:
+
+ * merged the vysos branch into the svn trunk
+ * updated and build the full ipp suite on cherry
+ * exported /home/ipp from vsysodata1 to the fruitbowl
+ * (Gavin) updated the fruitbowl automounts to place the main data disks in /exports/(hostname) as an local mount and /data/(hostname) as a remote mount
+ * added vysosdata1:/home/ipp to /data/vysos on the fruitbowl
+ * update the firewall to allow nfs and mysql traffic from the fruitbowl to vysosdata1
+ * added a 'vysos' user on the fruitbowl with UID matching the ipp UID on vysosdata1
+ * updated the database to change the named locations of the raw data (file://home/ipp/alldata/...) to abstract paths (path://RAWDATA/...)
+ * updated the fruitbowl site.config configuration file to point at the correct locations for the raw and processed data targets.
+
+Initially, I was going to have the processing read from /home/ipp/alldata/... and write results to /home/ipp/data/process.  However, it turns out that the directory 'alldata' is a simlink to /drobopro, which is in turn an HFS+ device.  Without a lot of work, I cannot NFS mount an HFS+ device on the fruitbowl machines.  I decided it would be easier to just copy the data that was going to be processed to /home/ipp/data/rawdata/... and update the database.  I defined path://RAWCOPY to point at the new location, and wrote a script (vysosdata1:~ipp/workdir/relocate.ic348) to copy the data and modify the database.  Although the script has the ic348 in the name, it will work for any data associated with a labeled chipRun.
+
+