Fedora cluster project? (was Re: [Beowulf] Opteron/Athlon Clustering)

[Mitchell Skinner]

On Tue, 2004-06-08 at 15:00, Robert G. Brown wrote:
> <rant> Ah, but you see, this is a religious issue for me for reasons of
> long-term scalability and maintainability, so I don't even think of this
> alternative.  Or if you like, I think it costs money in the short run,
> and costs even more money in the long run, compared to participating in
> Fedora or CaOSity and doing it once THERE, where everybody can share it.
> But you knew that...;-)

I've been kicking around the idea of starting a fedora-oriented cluster
distribution.

***Advantages of Fedora vs:

RHEL rebuilds (Rocks, cAos)
*  Don't need to do release engineering for the base distribution (cf.
Rocks 3.1.0 bug where i686 kernels were installed on athlon machines)
*  More up to date

Debian
*  More stable than unstable, less archaic than stable

Rocks
*  freely available update stream

***My goals for it would be:
Social/political goals:
1. Ease of installation ("yum install cluster-master")
2. piggyback on other work (Fedora release engineering, mobs of people
trying it out on commodity hardware)
3. Encourage outside contributions (have a completely open devel
process, use a license without an advertising clause)
4. Be an integration point for applications ("yum install mpiblast")
5. Feed back upstream (to fedora and/or directly to maintainers)

Technical goals/hopes:
1. Organize as a set of add-on packages, rather than a whole
distribution (like OSCAR, but without the extra complexity of multiple
base distributions).  This means creating SRPMs that can be fed upstream
(unlike rocks-sge, for example).
2. Use RPM/anaconda to select architecture-specific files, like Rocks
(handles heterogenous clusters more cleanly than systemimager (OSCAR) or
network booting (warewulf))

***Potential Objections:
1.  "Fedora changes too frequently" - This is problematic in proportion
to the pain of change.  One reason that change is painful is that people
put it off, and then have to make a huge change all at once.  More
frequent, more incremental changes can work, especially if you have the
source to your apps.  This is assuming that the still-somewhat-untested
fedora-legacy project doesn't work out; if it does then this objection
is moot.  OTOH, if you want your closed-source ISV apps to be certified
for your setup, then maybe this approach is not for you.

What do people think?

Mitch