[5354] in Release_7.7_team
Technical aspects of neo-Athena
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Oct 26 09:32:25 2005
Date: Wed, 26 Oct 2005 09:31:37 -0400
Message-Id: <200510261331.j9QDVbLf026229@egyptian-gods.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@MIT.EDU
X-Spam-Score: 1.217
X-Spam-Level: * (1.217)
X-Spam-Flag: NO
Background: the Future of Athena is currently under consideration by
IS&T management. We will probably not be doing a full release with
major upgrades next summer, and will either be pursuing a conservative
approach of cost reductions to the current Athena model, or an
aggressive approach of creating a neo-Athena optimized for
individual-use machines. See fuzz [4016]
(http://diswww.mit.edu/menelaus/fuzz/4016) for a summary. In either
case, there is likely to continue to be an environment of Linux
cluster machines, quickstations, or special-use machines which
resemble cluster-use machines for the forseeable future, although the
number of these machines may be reduced from the current number.
Although we don't have a green light for neo-Athena, I think we can
start to discuss some of the high-level technical aspects of such a
new system. (There are also interesting technical aspects to the
cost-reduction approach, but it's easier to focus on one direction at
a time.) Here are the ones I want to touch on for November's release
team meeting:
* Choice of distribution
* Installation
* Source tree maintenance
The name "neo-Athena" is a placeholder. As I noted in fuzz [4016],
neo-Athena might not use the name "Athena" at all, because so many of
the expectations about the term "Athena" might not be true any more.
Choice of distribution
----------------------
This issue has business ramifications for IS&T and would need to be
made ultimately by owls, but it also has technical ramifications.
Redhat Enterprise Linux provides significant value to Athena due to
its update model, where security fixes and hardware support are
backported to a stable baseline which is supported by five years
(though two years would probably be enough for us). In essence, MIT
can be seen as purchasing these backports as a service from Red Hat.
The same backport model applies to Debian Linux, but there are other
reasons we aren't using that distribution.
Neo-Athena would benefit from that backport model as well, but we must
strongly consider the goal of not requiring a reinstall for most
potential users of neo-Athena. RHEL is not the distribution of choice
for most existing installs because it costs money. Input from
consulting suggests that the most popular pre-existing distribution at
MIT is probably Fedora Core, with a significant amount of Debian. We
may be able to collect some further data on this by looking at the
browser strings of machines performing certificate renewals; Theresa
is looking into this through NIST.
If we adopt the "most popular pre-existing distribution" criterion,
then neo-Athena may have to be more agile in response to the market
than if we adopt the "best distribution for development and support
purposes" criterion we are currently using. If, say, Ubuntu overtakes
Fedora Core as the most popular pre-existing distribution at MIT, then
neo-Athena might need to shift to that distribution in some future
year. Since it would be nigh impossible to automatically update
machines from Fedora Core to Ubuntu, we would need to phase out one
system and phase in the other. If the most popular pre-existing
distribution becomes split between two distributions, we might find
ourselves trying to support both for an indefinite period of time.
Installation
------------
Right now we have our own installer script which drives rpm, and
installs RHEL 4 plus Athena RPMs. We do all of the system
configuration ourselves, using Red Hat tools like
system-config-display when appropriate. There are some obvious pros:
* Our install is reasonable for Cluster Services, Red Hat's less so
* We do Windows partition resizing, Red Hat's does not
and some obvious cons:
* Our interface is bare-bones text, Red Hat's is more user-friendly
* Our install is less flexible about system configuration
* We produce subtly different results from Red Hat's installer
Since we would likely be supporting a cluster-type environment of some
size, as well as a bunch of users who have a Windows installation and
would be creating a dual-boot machine, it might be interesting to see
if we can produce an installer which wraps anaconda rather than simply
wrapping rpm. Using anaconda's kickstart functionality, we might be
able to produce something which is reasonable for Cluster Services.
Prior to launching anaconda, we could examine the disk layout,
determine that a Windows partition resize might be appropriate, and
offer to do so.
Source tree maintenance
-----------------------
If we go the neo-Athena route, I would like to create a fresh new
source repository, rather than try to evolve the existing Athena
source repository. Some source code would undoubtedly be imported
from the existing Athena repository, as might the history of
Athena-originated code, but the wholesale history of the Athena
repository would not be converted.
I'd like to strongly consider using separate Subversion repositories
for separate components of neo-Athena, rather than one big repository.
This approach would work well if we have a component-oriented release
model; it would not work so well for a whole-system release model like
we currently have.
For source code we wrote ourselves such as larvnet, we could use
cvs2svn on a subset of the Athena repository to create component
Subversion repositories with history.
Despite our best efforts not to, it is likely that we will also want
to be modifying upstream code which is shipped by the stock
distribution. When we do this, I would like to start working with the
stock distribution's source package rather than the upstream
development source. For instance, if we are rebuilding openssh, we
would start with Fedora's or RHEL's openssh source package and add new
patches to it, rather than starting from the source code from
www.openssh.org. That way the behavior of our rebuilt package does
not differ as much from the stock distribution's package.
We need to consider how our rebuilds interact with distribution
updates to the same packages. Generally speaking, I think the
distribution's updates need to be put on hold until we can integrate
our changes into the new update. If we have a component-oriented
release model, that integration can be done more swiftly than in the
current whole-system model, where we have to push out a patch release
and make all our target systems reboot.
We can either distribute rebuilds under different names, using a
Provides: declaration to make them fit into the dependency system
under the old name, or we can distribute rebuilds under the same name
with a different release number. Since it's likely that we'll want to
give the user a choice between using the neo-Athena package or the
vendor package for each component, distributing packages under
different names is probably best, but we'll have to see what works
with the underlying update system.
