[Openais] Proposed change to default nodeid generation

[Steven Dake]

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
>