On Aug 20, 2008, at 11:54 PM, Steven Dake wrote: > 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
Why would there even be an autogenerated id if the admin had supplied one? If the admin asks for an id that overflows a signed integer, then thats what they get. I don't think anyone's suggesting we fold _all_ nodeids back into the 0..2^31 range, only that the autogenerated ones should be in this range. > 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
