[577] in Release_7.7_team
getcluster changes
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Jun 6 13:07:10 1996
Date: Thu, 6 Jun 1996 13:06:57 -0400
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
This is going to be long, because there are a lot of details to
consider. I'm going to save the section under "The new system" in
/mit/release/process/clusterinfo.
The old system
--------------
Hesiod cluster entries are of the form:
variable value version
where the version is sometimes omitted. If a version is present, the
entry is discarded if the version does not match the workstation
version. An entry with no version is used if all versioned entries
for that variable were discarded, or if there weren't any versioned
entries for that variable.
During the testing of a release, we have cluster information which
looks like:
syslib old-system-packs
syslib new-system-packs 8.0
7.7 machines would stay with the old system packs, so people would
have to manually detach the old system packs and attach the new ones
to update to 8.0.
After a release goes production, we have cluster information which
looks like:
syslib new-system-packs
7.7 machines would then take the new system packs automatically.
Problems:
* If a 7.7 machine is autoupdate FALSE, it will take the new
system packs but will not take the update. This will cause
the machine to become nonfunctional.
* During the testing of a release, there is no console
notification that a new release is available, even though
the user theoretically wants to take that release.
The new system
--------------
Hesiod cluster entries are of the form:
variable value version flags
where the version and flags may be omitted. If a version is present,
the entry is discarded if:
* AUTOUPDATE is false and the version does not match the
workstation version, or
* AUTOUPDATE is true, the version does not match the
workstation version, and flags contains 't'.
After discarding any such entries, the entry with the highest version
number is used to set the variable. An entry with no version is used
if all versioned entries for that variable were discarded, or if there
were no versioned entries for that variable.
If a versioned entry is discarded which did not have the 't' flag set,
the environment variable NEW_PRODUCTION_RELEASE is set to the highest
such version in the resulting cluster information. If a versioned
entry is discarded which did have the 't' flag set, the environment
variable NEW_TESTING_RELEASE is set to the highest such version in the
resulting cluster information.
During the testing of a release, we have cluster information which
looks like:
syslib old-system-packs 7.7
system new-system-packs 8.0 t
7.7 machines will stay with the old system packs, regardless of
whether AUTOUPDATE is set. However, the environment variable
NEW_TESTING_RELEASE will be set to 8.0, which will result in a console
message.
After a new release, we have cluster information which looks like:
syslib old-system-packs 7.7
syslib new-system-packs 8.0
If a 7.7 machine has AUTOUPDATE true, it will automatically get the
new syslib entry (and subsequently take the update to 8.0). If a 7.7
machine has AUTOUPDATE false, it will stay with the old system packs.
However, the environment variable NEW_PRODUCTION_RELEASE will be set
to 8.0, which will result in a console message.
Here's a matrix for resolution of versioned entries:
Matches No match, No match,
ws version 't' flag set no 't' flag
---------- ------------ -----------
AUTOUPDATE true consider discard consider
AUTOUPDATE false consider discard discard
And the versioned entry chosen is the one with the highest version
wasn't discarded.
The transition
--------------
A 7.7 patch release will go out with the new getcluster. This will
enable AUTOUPDATE true machines to take the 8.0 release when it goes
production. By happy coincidence, AUTOUPDATE false machines which
don't take the patch release also won't get the 8.0 packs when the
release goes out.
One question you might ask is: why do I have version numbers on the
7.7 syslib entries in the new system, when we didn't used to put them
there? The reason is that now that we aren't screwing people who
don't take major release updates, we may wind up having more than two
syslib entries at a time in the future, and it becomes more important
to make it clear which is for which version.
