> > 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@xxxxxxxxxx>
