[Openais] Proposed change to default nodeid generation

[Mark Fasheh]

On Wed, Aug 20, 2008 at 02:54:04PM -0700, 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 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.

But, if the ->auto_node_num() callback simply *replaces* the code within
openais which autogenerates node numbers, how does this change break
compatibility? I would assume that everything else proceeds as usual and
with the existing precedence for assigning node ids.


By the way, I'm not thrilled with the idea of pushing this onto the module
writers, but if it changes things from "cpg fakes a nodeid" to "nodeid is
uniform across all of openais" then it might be a necessary evil  :)
	--Mark

--
Mark Fasheh