Re: Compaq launches Open SSI Cluster Projects

[Alan Robertson <alanr@unix.sh>]

Bruce Walker wrote:
> 
> Alan,
>   We are very interested in working with any and all
> Linux cluster groups.  I haven't sent a response to
> your earlier message about your framework  because
> I haven't studied it enough to react intelligently.

I suppose you could have taken the alanr-approach, and commented on it
without feeling constrained by a lack of knowledge ;-)

Please keep in mind that the document is being written as we speak, and very
much subject to change.  I've made significant changes as a result of
feedback from the linux-cluster list, and hope to continue to do so.  Don't
hesitate to ask questions about the things which will inevitably be unclear
(or even wrong!) in it.

There are not yet any details on any APIs in the document.  There is an
incomplete list of API sets.

Having helped another large computer company open source some HA software in
the past, I know how time-consuming and frustrating this initial phase of
the project can be.  I'm sure you've come to know and love your lawyers ;-)

Speaking of this -- has COMPAQ committed to a license for the complete set
of software you're going to provide?

Of course, the GPL/LGPL would be the most harmonious choice, since every
other OSS project uses them.

If you're interested in some background on how I have approached HA designs
in the past, or my personal leanings, you might find it helpful to read the
heartbeat design document.  You might also try it you have insomnia, and are
don't like pills ;-)  It's here:
	http://www.linuxshowcase.org/2000/2000papers/papers/robertson/

> The desire to produce SSI cluster may add
> requirements to your framework.

Of course.  Producing an "X" cluster (for any "X") generally requires more
capabilities, and more APIs.  My big concern about APIs in this area, is
that the base set of APIs not be encumbered by the desire to add a set of
APIs for an optional feature for certain types of clusters (like SSI).

The set of APIs is not fixed, nor is it ever intended to be completely
fixed.  The idea is that you should be able to assemble a cluster out of the
components you need -- and leave out those you don't need.  That will
necessarily leave out certain APIs.  The set of APIs needs to be well
thought-out, well-designed and harmonious - but I don't see that it has to
be bounded by any particular hard boundary.  The set of libraries on a Linux
system isn't intended to be bounded, nor is the set of plugins for the GIMP.

> As for APIs, a
> set of proposed membership APIs is included in the
> Cluster Infrastructure project (along with all the code
> to build, boot and play with for clusters that may
> scale up to 64 nodes (haven't tested that big yet,
> though)).

Where can I find those proposed APIs?

> I would very much like to start a discussion on
> membership APIs (since in our experience, this is
> the first place an application might become cluster
> aware).

My two favorite areas are membership and basic cluster messaging.

By the way, keep in mind that in the framework, APIs are those things that
are exposed to the user *or* other cluster components.  So, basic messaging
will be of interest to other cluster components soon.

> I'll send the URL where you can review them.

Great!  On this note, I just added some general, semi-philosophical thoughts
on APIs to the document.

Looking forward to the URL...

	-- Alan Robertson
	   alanr@unix.sh

Linux-cluster: generic cluster infrastructure for Linux
Archive:       http://mail.nl.linux.org/linux-cluster/