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
