[Linux-cluster] Interfacing csnap to cluster stack

[Lon Hohberger]

On Tue, 2004-10-05 at 15:47 -0700, Daniel McNeil wrote:

> Why do we want to use Magma?  At the cluster summit I thought
> that Magma was just the way to provide backward compatibility
> for the older GFS releases.  Did we agree to make magma the
> API?

Sort of.  To be clear, it was originally written to provide a single API
for the clumanager package to run atop of CMAN+DLM or GuLM
interchangeably.  As such, it originally provided backward
compatibility. 

It may yet prove useful because it was designed, in some manner, to
function as a userland cluster switch, and is a proof of concept of such
a thing.  It should be possible to add other cluster APIs to magma.  At
least, I certainly hope it is.

> Having csnap depend on the DLM API makes more sense to me.

This design precludes using csnap with a GuLM cluster.  Using Magma does
not.  (Clarification: by "cluster lock", I meant precisely that - GuLM
provides this functionality, as does the DLM.)

If there is no reason to use csnap on a GuLM cluster, then it should
probably use the native CMAN + DLM APIs.

> The cnap-agent to csnap-server seems like a perfect example of why we
> a cluster communication API.  The csnap-agent wants to send information
> to the csnap-server and could use a highly available communication
> mechanism.

Magma provides spartan TCP messaging (basically, wrappers around
everyday syscalls), which may not work for all cluster applications (no
group messaging at all).  Furthermore, that bit is derived from GPL
code, which makes it unsuitable for *all* proprietary applications.

CMAN provides some group messaging capabilities, but I don't know about
the messaging ordering guarantees.

Messaging is certainly a topic which will need to be discussed more in-
depth.

-- Lon