next up previous contents
Next: Recommendations Up: Report of the Layered Previous: Summary of Recommendations

Layered Athena Can Expedite Ports

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.

next up previous contents
Next: Recommendations Up: Report of the Layered Previous: Summary of Recommendations

Bruce R. Lewis
Mon May 19 16:06:37 EDT 1997