Re: A proposal for a General Clustering Framework

[Alan Robertson <alanr@unix.sh>]

Michael E Brown wrote:
> 
> I'm sorry. I don't think I communicated an important point that I had on
> my mind when I was composing the original msg.
> 
> I was not advocating that you use XMLRPC for certain things such as
> cluster heartbeat, which have to be slim/trim/no memory leaks/etc. But I
> do think it would be easier from a library standpoint if the messages that
> you were multicasting were in an XMLRPC-compatible encoding. I think David
> Brower's point that XMLRPC is very powerful and can encode just about any
> C struct or datatype is valid.

What I need is something that encodes *more* than 'C' language datatypes. 
For example, 'C' has no concept of lists or name/value pairs.  We need
those.  Even heartbeat needs them at the lowest levels.

But, if one frees one's mind from thinking about "struct" as the 'C' keyword
'struct' and instead think name/value pairs, then things suddenly seem
reasonable.

I can see NO reason not to use the same encoding for everything.  More to
the point, I can see *many* reasons to use the same encoding everywhere -
including heartbeats.
 
> What I was thinking of is another layer on top of the shared
> hearbeat/cluster manager/etc framework. An XMLRPC transport so that
> _third party_ applications have a well-defined interface into the core
> cluster managment interfact.

I agree.  But, I think there should only be one mechanism.  Perhaps two
encodings, but only one API (and one mechanism).

> XMLRPC IS NOT appropriate for
>  1) low-level heartbeat: SendHeartbeat()
>  2) cluster manager stuff/membership services:
>  3) actually performing stonith: StomithKillNode()

Actually, I would VERY DEFINITELY want to use the same mechanism for
everything.  Without a doubt.
 
It might be the case that the sender could select their preferred encoding.

At this point, I think I understand enough to say that it's not a matter of
semantics or the APIs, but of how the data gets encoded onto the wire that's
a concern to me.

I suspect that it would be easy to come up with XML-RPC-slim, and the sender
could select whether they wanted to send XML-RPC or XML-RPC-slim encodings
of their calls.

And, it is equally important that calls be allowed to not require any kind
of explicit reply, and that there be an addressing mechanism around it which
allows multicast/broadcast/directed addressing of packets.

Clearly whatever we do will BY DEFINITION be a significant extension over
the XML-RPC spec.

1) we won't support HTTP
2) we will allow calls without explicit replies (event notification)
3) we need to indicate which domain the message is within.  By that I mean
	which application program on the destination end will receive the
	call...


This is kinda cool...

I also thought of a third extension:

3) Allow calls to multiple nodes in the cluster.  There would be another
parameter for the list of machines in the cluster to be called, and one for
a timeout value.  The caller would be notified once all the replies came in,
or timeouts had occurred, or (optionally) cluster membership had changed...

This would be very nice.  It's really what several parts of the HA code
would like...

	-- Alan Robertson
	   alanr@unix.sh

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