[317] in Release_7.7_team
For the record: hesiod
daemon@ATHENA.MIT.EDU (Dorothy Bowe)
Tue Jun 6 10:33:12 1995
To: release-team@MIT.EDU
In-Reply-To:
Date: Tue, 06 Jun 1995 10:33:02 EDT
From: Dorothy Bowe <dot@MIT.EDU>
Since I volunteered to deal with hesiod, clusters, and system packs, I
decided to write up some notes on the process for the next round. I'm
sure this is not complete and probably uses some terminology
incorrectly, but at least it's a start.
You can probably delete this now; I mostly want it to get archived in
discuss until I get ambitious enough to convert to html...
dot
Releases and Moira
==================
Background
**********
Moira manages two (2) pieces of information which play a part in an
Athena release. First, each workstation is associated with a system
library entry in a cluster. These clusters are not physical entities
but rather virtual groups of machines. Being in a particular cluster
does not do anything in and of itself. It is the second piece of
information, the cluster to file system (filsys) entry which ultimately
associates a workstation with a particular system pack.
workstation in cluster &
cluster associated with system pack
-> workstation gets system packs
For example:
athena% hesinfo pianoforte cluster
syslib beta-sun4sys
lpr hp-test
athena% hesinfo beta-sun4sys filsys
AFS /afs/dev.mit.edu/system/sun4c_53/srvd n /srvd
So my workstation currently gets its system packs from the dev cell.
There has been some discrepancy as to how these paths are specified:
whether they use an @sys link or the actual string, and whether they
name a particular release (srvd8.0) or a generic entry (srvd) which is a
soft link to a particular release. Be careful if you use @sys combined
with srvd; you can workstations which haven't updated getting weird
system packs and weird results because of operating system changes. I
don't know for sure, but I prefer using explicit paths for the srvd.
athena% hesinfo public-dmusys filsys
AFS /afs/athena.mit.edu/system/pmax_ul4/srvd.77 n /srvd
** YOU MUST USE EXPLICIT PATHS FOR THE PUBLIC PACKS. **
We historically have used three different clusters of machines when
rolling out a new Athena release:
beta
early
public
(There is also an alpha cluster used strictly by release engineering.)
The "early" cluster is sometimes implemented in two pieces: those
workstations belonging to staff members, and those workstations located
public clusters. (The physical clusters in this case.) The two parts
are managed by changing which cluster a machine is in, early-* or public-*.
As of June, 1995, the clusters are named with the prefixes beta-,
early-, and public-. e.g. early-dmu, beta-sun4, public-sgi. You
can get a listing of all cluster named with a prefix by using the moira
menu cluster menu (#1) and choosing option 1 (Show). By entering a
wildcarded name such as public-* or early-*, you can get a listing of
all clusters matching the string.
Implementation
**************
1. Beta test
Before release engineering starts building the new system packs in
the dev cell, make sure that no other workstations are getting packs
from this location. Check the syslib entries for beta and early
clusters using the cluster data menu (#6 on the cluster menu),
choosing option 1 (show) and entering beta-*, syslib and early-*,
syslib, respectively. This will give you the system library entries
for these clusters. If the early-* clusters get the packs from
public areas (i.e., the syslib entry is public-<something>), you can
ignore them.
To change the information for all those machines currently getting
packs from the dev cell, we can either change the filsys entry for
each system pack, or we can change the syslib entry for each cluster.
To change the filsys entry, use the filsys menu and change the
information for each entry (e.g. beta-sun4sys, beta-dmusys) to point
to the same location as the public packs. (Definitely change the
early-* clusters to point to public packs if they don't already.)
It's probably easier to do the second option, changing the syslib
entry for each beta- cluster, making the entry public-<thing>.
[Build the new packs, copy them into the dev cell and replicate 'em.]
When ready for beta test, change the syslib entries back to
beta-<thing> and make sure that the filsys entry is correct.
For example, with Release 8.0, change the cluster syslib entry
beta-sun4 back to beta-sun4sys, and the filsys entry (beta-sun4sys)
to
/afs/dev.mit.edu/system/sun4c_53/srvd8.0
2. Early Test
When ready for the early testers, point the early-* clusters at the
same syslibs as the beta-* clusters.
e.g. early-dmu -> beta-dmusys
3. Release
Actually doing a release involves copying the packs to the Athena
cell, replicating them, and changing the filsys entry for the
public-* clusters. **Do not** use soft links (srvd -> current
release) for the public release; all the public workstations will
see the change at one time and cause an update load problem.
Misc
****
To get a list of machines in a cluster, use the Cluster -> Mappings ->
map, and enter *, <cluster> (e.g., *, beta-sun4).
