Re: A proposal for a General Clustering Framework

[Michael E Brown <michael_e_brown@dell.com>]

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 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.

For example, the API for an application to use that is sitting on top of
the cluster, or for things like non-core cluster application monitoring
scripts and programs.

XMLRPC IS appropriate for (with a completely made-up example API :-)
 1) Application cluster membership query ->ListClusterMembers()
 2) Application status query ->QueryNodeStatus()
 3) application monitoring/start/stop scripts ->BeginResourceStartup()
		->ResourceRunning()
		->ResourceFailure()
 4) Configuration:
	->ListStonithMethods()
	->StonithConfig()
	->NetworkConfig()

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

So, what I would imagine is a core API that uses shared-libraries and XML
as it's communication method for the "Highly-Available" part of the
cluster management.

Then there would be an XMLRPC wrapper around the "Administrative" part of
the cluster managment. Right now, shell scripts certainly play a large
role in cluster managment. I would envision moving towards a
Python/Perl/C/whatever based structure, and the good thing about XMLRPC is
that it would allow you to freely choose your implementation language for
these functions, but your API would always stay the same. And with the
added benefit that you would not have to write wrappers for any of these
languages.

Hopefully I have been a bit more clear this time :-)

--
Michael


On Mon, 4 Jun 2001, Alan Robertson wrote:

> Michael E Brown wrote:
> >
> > Thanks for the PDFs! I hadn't gotten around to installing StarOffice on my
> > Debain box at home yet.
> >
> > After having looked at the paper, I see the purpose of the previouse
> > xmlrpc/soap discussion. :-)
> >
> > So, now that I know you are actually going to use XML as your interprocess
> > interchange format, I feel strongly that using the smallest subset of XML
> > that is compatible with XMLRPC would greatly benefit the overall project.
>
> Unfrotuantely, XMLRPC is not nearly powerful enough.  I need to send
> basically arbitrarily complex data structures back and forth.  It doesn't
> have name/value pairs, or attributes, etc.  So, XML-RPC isn't very
> attractive thing to build on for clusters...
>
> I'll see if I can come up with an example that I *know* I'll have to deal
> with in configuring Stonith modules...
>
> 	-- Alan Robertson
> 	   alanr@unix.sh
>


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