Subject: Long Jobs history #4 Date: Thu, 08 May 1997 17:45:55 EDT From: "Naomi B. Schmidt" ------- Forwarded Message Received: from SOUTH-STATION-ANNEX.MIT.EDU by po6.MIT.EDU (5.61/4.7) id AA26775; Thu, 13 Jul 95 15:43:26 EDT Received: from MOZART.MIT.EDU by MIT.EDU with SMTP id AA07656; Thu, 13 Jul 95 15:43:23 EDT Received: by mozart.MIT.EDU (5.57/4.7) id AA13528; Thu, 13 Jul 95 15:43:22 -0400 Message-Id: <9507131943.AA13528@mozart.MIT.EDU> To: tom@MIT.EDU, matt@MIT.EDU, carla@MIT.EDU, ellis@MIT.EDU Cc: miki@MIT.EDU, nschmidt@MIT.EDU, gjackson@MIT.EDU Subject: Notes from July 12 "Long Jobs" meeting Date: Thu, 13 Jul 1995 15:43:20 EDT From: "Naomi B. Schmidt" We decided to step back and look again at what we're trying to accomplish and why, laying out all alternatives and examining their pros and cons. 1. Do nothing Pro: - it's the easiest way out Con: - leads to bad customer perception of IS - negative educational impact - people will continue to tie up workstations 2. Set aside reservable workstations Pro: - no development work required Con: - we don't have the space for additional workstations - users would need to be there - it would be a burden on cluster support people 3. Restricted dialup servers Pro: - none that we could think of Con: - people need to stay logged in while their job is running - inherent insecurity of a time-sharing system - hard for us to manage 4a. Resurrect "submit" (aka the patriot model) Pro: - it's easy for us, being an old hat solution Con: - it's somewhat subject to abuse by users - we'd need to be sure it's less flaky than the VAX9000 - inherent insecurity of a time-sharing system 4b. "submit" (patriot) with a restricted password file This would be less subject to abuse than a system when anyone can use it. Courses or individuals would have to "register" to use it, which would add some administrative overhead, less for courses than for individuals. 5a. 3rd party Batch software (authenticated) Pro: - it can manage priorities well - we can constrain users' use of the machine's resources Con: - it's something new and untried in our environment - inherent insecurity of a time-sharting system - authentication is difficult and needs some work 5b. 3rd party Batch software (unauthenticated) Pro: - same as above Con: - leaves users vulnerable - inherent insecurity of a time-sharing system [Note: on the board at our meeting we had "load balancing" as a Pro under numbers 4 and 5, but I didn't put it in here because I don't remember what we meant. Does anyone else remember what it means?] Next steps: - ---------- 1. Find submit software [Carla found it in the patriot locker] 2. Talk with Miki, Karl [Naomi spoke with Miki, who will think about issues with submit when she gets back from vacation in two weeks] 3. Develop a plan 4. Configure and test software on two SPARCclassics or SPARC5s 5. Buy hardware * 6. Launch pilot with a few selected subjects 7. Tweak software/process 8. Re-evaluate and possibly either expand this model or else put resources into using 3rd party batch software (option 5 above) * Possible hardware - 2 SPARC20/4 4 Gig disk (incl 1 Gig swap) 256 Meg RAM Note - In my conversation with Miki, she expressed some doubts about using a hacked together "submit" so that we can have good authentication, and suggested that it might be preferable to use commercial batch software with less stringent security (i.e. solution 5b above) for the "pilot" phase. When she returns from vacation, she will look over what were the weaknesses of Patriot and which ones will still potentially be there even with a more supported platform. We should invite her to meet with us once she has done that so that we can further evaluate the pros and cons of solution 4 vs solution 5 above. ------- End of Forwarded Message