Discussed timeline and sequence for this.
* A web cluster will be created (only mustard to begin with) that will handle all web apps (in the case of Cocoon apps, it will - as it does now - handle the port 80 end of things). Mustard will become mustard.hcmc.uvic.ca and will be built up with RHEL5-64bit and all current s/w required (Apache, PHP, MapServer, etc.). As far as h/w goes, RE figures the 3GB RAM we have in mustard and lettuce is sufficient.
* Chard DBs will be either retired or migrated to Cress. Chard will then be rebuilt with latest/greatest (RHEL5-64 and so forth) and redeployed (as chard.hcmc.uvic.ca). Once it's handling the DBs entirely on its own we need to decide how to use Cress (more on that in bit).
The plan is to have all HCMC machines behind the main UVic load balancers; all outside requests go through the load balancers.
Mustard and (eventually) Lettuce, will be a web cluster of two, and will be the application servers for all PHP/SQL apps, as well as handling all port 80 requests to our Cocoon apps.
All Tomcat/Cocoon requirements will be handled by Pear and fronted by Mustard/Lettuce/load balancers.
All SQL-type DB requirements will be handled by Chard. (We need to decide how best to use Cress in future. Choices include mothballing it, replacing Lettuce with it, or continuing to use it as a running back-up for Chard. Although the safety advantage of the latter is good, it seems like a bit of a waste of a machine - anyway, we have time to discuss this amongst ourselves.).
So, the sequence and timeline go something like this:
RE would like to begin work on Mustard by mid next week (as in August 4th). To do that he needs the go ahead from us; I'll be going through a final check today/tomorrow.
Once that's done (RE figures it shouldn't take more than about a week to get mustard back on its feet) Chard gets similar treatment - migrate necessary DBS, mothball the others, rebuild machine, redeploy, populate new DBs. Again, this is about a week's work. Ideally this will all be done by mid-August.
Subsequent work will be to do the same thing to Lettuce and Cress, but we don't have a timeline in mind for them yet.
What HCMC needs to do
* Check that mustard is ready to be rebuilt.
*** Martin has already dealt with the most problematic aspects of this, but we should probably make sure that incoming requests to places like the ACH/ALLC 2005 proceedings (like mustard.tapor.uvic.ca/cocoon/ach_abstracts/xq/xhtml.xq?id=176) get handled as redirects to Pear. I notice that if you search for "The Edition Production Technology (EPT) and the ARCHway" you come up with some hard-coded links to mustard - I'm guessing that isn't *too* uncommon.
* as an aside, RE will be moving virtual hosts on mustard to lettuce and viola (there are still two VHs on mustard for ise and tapor)
* RE will give us a dump of DB names on Chard - I'll track down owners and let them know what's going to happen (RE locks the DB, dumps it, restores it on Cress, we test)
* once mustard is ready, RE will provide dev ipnames for our existing virtual hosts, and we can begin migrating our PHP/etc. apps from lettuce to the new mustard.
* discuss what we're going to do about stuff like Ruby. Plans are (I believe) afoot to rebuild the apps relying on Ruby, but I don't know if there is a timeline yet. RE and I discussed the idea of using Fennel to host a wee VM running the oddball stuff that we plan to drop of over time (we could call it detritus.hcmc.uvic.ca).
* we also need to address the home1t issue. It's still big and unwieldy in an emergency, and we need some of the space for Fennel's OS storage. We have some time, but we really need to trim our use of home1t and make it shrinkable.