[MOBY-dev] Tentative plan for the MOBY Central move

[Mark Wilkinson]

Hi again everyone!

It looks like the new Moby Central is working correctly and all  
accessories (RESOURCES script, LSID resolver, etc.) are working on the new  
machine.  All we need now is a plan to deal with 24 hours of chaos when we  
shut-down the old server and switch to the new one.  I've been trying to  
find a way to make Apache redirect POST data to an alternate location but  
it apparently cannot be done in any "sensible" way (a bug or a feature??   
I'm not sure...).  Anyway, it means that we'll have to all switch at ~the  
same time.

My plan for the moment is this:

1)  Announce the date/time when the switch will happen - the old server  
will be *switched off* at this time to ensure that we don't get out of  
sync.

2)  I have re-coded the Perl stack (but haven't yet committed it...  
probably this weekend when I'm really really sure!). It now calls  
http://biomoby.org/mobycentral and scrapes the 302 Location header from  
that to determine where MOBY Central really is.  This will help ensure  
that any future move (if necessary) is not so painful.

3)  The Perl stack still uses environment variables as its default if they  
are available, so it will be possible to update your code without forcing  
the switch to the new server.  Just set the MOBY_SERVER and  
MOBY_ONTOLOGYSERVER environment variables to point to the old MOBY Central  
until the switch happens.  (hopefully the Java code will also do something  
similar?)

4)  On that date/time, I will make a clone of the current MOBY Central  
database from mobycentral.icapture.ubc.ca and move it to moby.ucalgary.ca,  
then shut down the old server completely.

Basically, a CVS Update is all that should be necessary to make the switch  
 from old to new registries.

After more than a month of struggling, we were unable to get MOBY Central  
to run in 64-bit (combinations of libxml.c problems and mod-perl  
problems), so the wonderful and patient sysadmins in Calgary spent a lot  
of time and effort in re-compiling everything in 32 bit so that it all  
works for us!  I sincerely appreciate their commitment!!!!  Thanks to them  
(and I owe them a couple of bottles of scotch, apparently...)  In any  
case, the server in Calgary should have much better connectivity for  
everyone, so it should all run much faster after the move!  The only  
exception is RDF generation (i.e. the RESOURCES script) since everything  
in MOBY Central is now pure-perl, and the RDF::Core libraries are  
significantly slower than their Java counterparts.  Eddie is working on a  
caching mechanism for the RDF, so hopefully it wont be *unusably* slow  
(apparently it took 15 minutes for Dashboard to load the RDF today without  
caching... UGH!)

Just as an aside, I was playing with the LSID resolver a couple of days  
ago and I have working code that merges the RDF from all possible metadata  
endpoints into a single graph.  I'll post it to the list if anyone is  
interested (or just go to my blog:  semanticmusings.blogspot.com since I  
also posted the code there for the sake of the HCLS community).  The point  
of that excercise was that we want service providers to be able to give  
example input/output to their services in their RDF Signatures, but until  
now we never had the code that could retrieve metadata from anywhere other  
than MOBY Central.  Now we do!

If anyone has any questions or concerns about this plan (e.g. if you are  
holding a workshop in the next week, and want to be sure that MOBY Central  
is not "dead" when you try to reach it!) please say so and we'll schedule  
the move around your event.  If it is going to be extremely troublesome we  
can delay the move until Christmas.

Best wishes everyone!

Mark