At the beginning of the Layered Athena project, it was hoped that a new model for software installation could replace the current model, which is development-intensive and time-consuming. The Layered Athena team has come to understand that the current model for installation is not yet ready to be replaced, because Layered Athena does not meet the requirements detailed in section 4.2. However, Layered Athena is still useful as an interim installation procedure before machines are installed in public clusters.
A timeline for a non-layered port can look something like this:
cluster deployment DCNS dev: | srvd aabbccbcccbccccbcccccbccccccbcccccc|bbbccc inst1 ---------aaaabbbbcbccbcccbccccbcc--| inst2 -------------------------aaaabbbbcc|dd Non-DCNS dev: | srvd ---------------------cbbbccbcbccbcc|cbcccc lockers ---------------------------aabbaabb|aabbaa
In this timeline, the symbol (-) means nothing is done, (a) means development work, (b) means finding and fixing bugs, (c) means use, and (d) means documentation. The port starts with developers doing the simplest task, which is building system packs (srvd). After the srvd has undergone some developer testing, it needs to be installed on several non-developer machines for further testing, and so that key personnel can familiarize themselves with the new platform.
To install these machines, it isn't necessary to have a procedure that fits all of the cluster group's requirements, so an intermediate procedure is developed (inst1). Depending on what roadblocks are encountered, this procedure can take as long to develop as the final install procedure. It may need handholding, meaning a developer needs to be involved in every installation. This can take a significant amount of developer time away from debugging the srvd and writing the final install procedure.
As the time approaches to put machines in the clusters, the final install procedure (inst2) must be written. Because of the load on developer time up to this point, inst2 is saved until the last minute, and finished just in time.
Courseware, applications and tools in various lockers need to be compiled on the new platform. Unfortunately, groups such as ACS, CSS and SIPB don't get the srvd software until relatively late in the game, and must scramble to get everything working. It's expected that a lot of locker software just won't be ready until well after the new machines are deployed in clusters.
Layered Athena makes possible a totally new timeline:
cluster deployment DCNS dev: | srvd aabbccbccbbcccbbccccbbccccccccccccc|cccccc layer ----abc----c----c-----c------------| inst2 ----------aaaabbbbccdd-------------| Non-DCNS dev: | layer -------c---c----c-----c------------| srvd -------cbbbccbcbccbccccbccccccccccc| lockers -------------aabbaabbaabbaabbaabbbc|bcbccbccc
After the initial srvd has been built and lockers can be attached, porting Layered Athena to a new platform takes less than a week. (Later, when a vendor introduces a new OS version with binary compatibility, the Layered Athena software developed for the previous version should continue to work with little or no modification.)
New machines other than the ones developers are using should be delivered with the native operating system pre-installed. The Layered Athena GUI can then be run without any developer assistance to install srvd software, and to easily take updates as they become available.
As a result, the srvd gets more testing sooner, developers are freed up to work on the final install procedure, and work on locker software can begin long before machines hit the clusters.
The initial srvd need not be complete. Login, the most difficult part of the srvd, is not essential for private workstations. The native login can be used, along with a script called login_athena which includes all the elements of an Athena tty login. Users get their usual prompt, shell, PATH, aliases, etc., and can port locker software in the environment to which they have become accustomed.