On Thu, 2008-08-21 at 09:48 +0200, Andrew Beekhof wrote: > 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. >
The patch you proposed breaks compatibility on the wire to achieve this result. Further it does this in the totem layer which other third party libraries can use. There is no way to fold autogenerated node ids into a 31 bit address space without breaking wire compatibility if it is done in the totem code itself which is who generates the node ids. > > 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
