Subject: Long Jobs history #4
From: "Naomi B. Schmidt" <[email-masked]>
Date: Thu, 08 May 1997 17:45:55 EDT

------- Forwarded Message

To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Notes from July 12 "Long Jobs" meeting
Date: Thu, 13 Jul 1995 15:43:20 EDT
From: "Naomi B. Schmidt" <[email-masked]>

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