On Wed, 2008-08-20 at 14:41 -0700, Joel Becker wrote: > On Wed, Aug 20, 2008 at 11:17:18AM -0700, Steven Dake wrote: > > On Wed, 2008-08-20 at 18:52 +0200, Andrew Beekhof wrote: > > We talked on irc and came to the conclusion that apparently it is > > impossible to fix the kernel issue with the assumption of 1^31 bits and > > it is impossible to fix the openais/corosync assumption of 1^32 bits > > nodeids. > > Boy, are we awesome. > > > Therefore a patch (with man page) of an api that gets the nodeids in 31 > > bit fashion from cpg would be workable. > > > > ie: > > > > cpg_nodid_31bit_set(handle). > > > > would be suitable if this would meet everyone's needs. > > Well, what happens with CLM? Does it report the 32bit nodeid? > What about EVS? Btw, it's interesting (though irrelevant) that EVS uses > 'unsigned int' instead of uint32_t. I think this is a little more core, > and I'd like to explore what we're really after. > I don't think we should force all openais/corosync nodeids to > 2^31 bits. The protocol should stay 2^32 bits. I don't think Andrew > was asking for this either. > I think Andrew was just looking for a way to limit the > autogenerated node numbers, because his software uses the > autogeneration. The cman stack never cares because it sets the nodeids > itself, which requires a configuration file and explicit nodeid > specification by the admin. > So, first, Andrew, does pacemaker have a method for querying > membership and nodeids? Forget ocfs2_controld/dlm_controld. I just > write a random application, and I want it to use pacemaker. Are there > functions for "what is my nodeid?" and "what nodeids exist in the > cluster?"? What do those functions look like? I'm assuming they work > in the absence of cpg, so it isn't just cpg here. > Both Andrew and Steve, I'm assuming that pacemaker exists as a > kind of corosync plugin these days. So it has some access to the config > space. Now, the cman config plugin fills in the nodeids, whereas > pacemaker appears to get them from corosync's automatic method. Is > there any way a plugin could have a hook from the autogeneration code? > That is, corosync determines it should be autogenerating a node number, > so it calls ->auto_node_num(). This defaults to the current IP address > method, but pacemaker could provide a new method that returns whatever > value it wants. Internal to corosync and on the wire, it's still > stored/sent as uint32_t, just like cman's nodeids. > > Joel
This would require transmitting both the autogenerated and the non-autogenerated nodeid over the wire to transmit it up the stack to the plugin's various node id functions such as confchg et al. That would break protocol compatibility. Regards -steve > _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
