[Linux-cluster] Re: Csnap server cluster membership interface

[David Teigland]

> > I'm getting attached to the idea of teaching cman to hand out port 
> > numbers along with service groups.  This needs to be kicked around, but 
> > it will eliminate considerable configuration annoyance, and perhaps 
> > most of the "well known" cluster ports, which is cruft that cman really 
> > shouldn't encode into its header files if we can avoid it.
> 
> I'm not sure that you will be able to get Dave to add this.

We need to clear something up:  service groups (or SM in general) are not
really related to the communication channels/ports that cnxman provides.

Again note that cman has two very distinct parts: cnxman and sm.  At the
moment, the sm functions are exported to userland via ioctl's on cnxman
sockets.  These sockets are often bound to cluster ports for communication
(not always, see fenced), but that communication is really a function of
/cnxman/, not sm.  SM has nothing to do with these ports or the cluster
socket communication.  SM is just taking advantage of the sockets as a
convenient way to do ioctl's.

This can obviously be confusing at first.  Right now cnxman and sm are
combined into cman, but at some point I expect we'll split them apart.  At
that point, SM functions will be exported to user space in their own way,
e.g. a char device.  There won't be cluster sockets to get a free ride on.

So, what you need to do is think separately about the SM functions and
communication.  SM is just there to give you the nodeid's of other service
group members and tell you when they change[1].  On their own, these
nodeid's are useless.  You can take them, though, and use the standard
cluster manager (cnxman) functions to map them to IP addresses, node
names, etc.

Patrick is the expert when it comes to cluster sockets, ports and the kind
of communication you can do there.

[1] Note that in the mail in which I outlined how you might apply SM to
this problem, I don't believe I said anything about csnap-specific
communication.

(One of the reasons to stay clear of some of the "fringe" capabilities is
that we can only be certain the "main" functions will remain as things
change down the road with us cooperating with other cluster projects to
produce common infrastruture.)

-- 
Dave Teigland  <teigland at redhat.com>