| Title: | Digital UNIX Object File/Symbol Table Notes Conference |
| Moderator: | SMURF::LOWELL |
| Created: | Mon Nov 25 1996 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 71 |
| Total number of notes: | 314 |
I'm reviewing the UNIX Rolling Upgrade specification.
UNIX is getting serious about clusters, and with Steel they are going
to be of similar capability to VMS Clusters. With this increasing
emphasis, they're getting serious about supporting rolling upgrades to
the cluster. This means that clusters can be upgraded to a new version
of the OS one node at a time, and then when all are upgraded, the
administrator can throw a switch that enables new functionality.
What does this mean for us? My opinion is that we should follow the
rules when it comes to changes that would affect an existing
application recompilation--so that the program will run and be
debuggable on any node in the cluster on which it was compiled.
If the user has to write a new program (or modify one) to get newly
available capabilities/formats and those capabilities are only
available on the upgraded cluster members, it is his/her problem when
it doesn't run on non-upgraded members.
What does following the rules mean?
UNIX is providing an API which will return the "running" version of a
cluster. The running version is the version the cluster is upgrading
from, until all nodes have been upgraded and the system administrator
has issued a switch version command. When the switch is thrown, the
upgraed version becomes the running version. Following the rules
would mean that we use the API and not use any format changes which
occurred after the running version.
Stated another way: any changes we're targetting for Steel that require
coordination between components should execute conditionally based on
the API's return value.
Randy asked how this is different from compiling on a new system and
taking the executable (or objects) to an older system and expecting
them to work. My answer is that a cluster should be thought of as much
more like one unified system than several independent systems. A user
who logs into the cluster and compiles /links an application today,
should be able to log into the cluster tomorrow (on potentially a
different node) and debug the application.
Also, the time frame is short. This doesn't require multiple OS
releases to get new capabilities, it just requires the sysadmin to
finish the upgrades and throw the switch.
Well, that's my opinion. Comments?
-Al
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 66.1 | withdrawn | SMURF::LOWELL | Tue May 06 1997 13:44 | 26 | |
This proposal has been withdrawn by Al Simons based on additional discussions with the cluster group. See below... Date: Thu, 01 May 1997 12:38:05 -0400 To: [email protected] From: Al Simons <[email protected]> Subject: Development environment in a cluster rolling upgrade environment I have previously raised the concern about what the DE should do in a cluster rolling upgrade. Specifically should our components be smart enough to not make format changes, etc., if we are in the middle of a rolling upgrade? >From a user standpoint, the question is whether, on a cluster running both Vn and Vn+1, should an artifact built on a node running Vn+1 be able to be consumed by a tool running on Vn? The cluster group is comfortable with the answer "No." Their belief is that there is a longstanding policy of not running on previous versions something built on a later version. The cluster group believes that the DE can be entirely cluster unaware. | |||||