Note that this list of links does not pretend to be either exhaustive or current. Still, if you find a dead link or have a site that just has to be added, feel free to send it in via the site maintenance link at the bottom of the page.
It does have an attractive suite of tools to choose from, including some simple cluster shell variants (gexec, pcp, pconsole). Some of these don't use ssh, and newbies should be warned to very carefully assess their security requirements before using them EVEN in a cluster that is fully isolated behind a firewall.
The only tools I see "missing" are SGE (which is a pain to build and a REAL pain to rpm-ify, so encapsulating it for RPM builds would be a real service) and perhaps Condor, to provide an alternative policy tool. Choice is good.
Parenthetical Aside With all those advantages, it is nearly ideal for clusters devoted to embarrassingly parallel tasks. The only catch is that it is SO powerful, and intended to build and run on SO many architectures, that one gets the definite feeling that it would build more simply and work better if most of those architectures were trashed and energy focused on linux and gcc-based systems. aimk, for example, is something I once played with and even hacked for my own extensive use back when I was managing a highly heterogeneous Unix network. Ah, what a child I was.
Eventually I sobered up and realized that heterogeneity is the root of a lot of evil where systems management and application developement are concerned, and that I really wanted NOT to EVER AGAIN have to screw around with where this particular flavor of Unix keeps that particular include file and how to hack and patch the code if the file (and its associated library) were different and possibly incompatible. Especially in a complex application with many contributing developers and nonlinear constraints (like support by Sun, making it impolitic for a Sun build ever to break) where somebody working on architecture X can break the hell out of architecture Y and not have the fact revealed until extensive testing has occurred on all the A-Z architectures "supported", requiring yet another #ifdef instrumentation.
Still, SGE (like PVM) will undoubtedly prove to be worth the hassle in the long run. In the meantime, one can only ask WHY the developers put four or five steps into the README.BUILD instead of providing a single script entitled "build.sh" or (better yet) a toplevel makefile with autodocumenting targets? So fine, maybe aimk is great, but normal humans have never used it so hide it behind regular old make. Or why they use the incredibly arcane aimk at all instead of Gnu's autoconf (intended to satisfy the same purpose, but a lot more modern and in common enough use to actually be functional)? Or (being the linux bigot that I am:-) they don't just scrap even this and focus on linux/gcc builds only with a Makefile a child could understand?:-p
Our site REQUIRES rpm's (ideally built from src rpm's so they can easily be REbuilt) for scalable management purposes. Building SGE into portable RPM form looks like it will be a truly joyful process. Especially given that following the strict instuctions in README.BUILD on a clean checkout from the CVS tree has failed every time I've tried it, most recently on a perfectly updated RH 7.3 system. For that reason I've been slow to get enthused, although this summer I may have the time required to get over the initial build blues.