[Openais] Proposed change to default nodeid generation

Steven Dake sdake at redhat.com
Wed Aug 20 10:01:28 PDT 2008


On Wed, 2008-08-20 at 18:52 +0200, Andrew Beekhof wrote:
> On Aug 20, 2008, at 5:25 PM, Steven Dake wrote:
> 
> > This breaks binary compatibility within the protocol.
> 
> I can't imagine how...

The nodeid is sent in the totem headers.  If it is mangled on one node
and not another node, then binary compatibility is broken.

> It introduces the possibility of duplicates but how is it any  
> different to the admin manually specifying the alternative value?
> Also, the admin can still manually ask for numbers beyond the positive  
> range of a signed integer and this code will not touch it.
> 
> > It is also completely unsavory to me.
> >
> > Finally what is the advantage of converting negative nodeids to  
> > positive
> > ones?
> 
> Did you read any of what I wrote besides the patch?
> 

Yes I did.  I don't understand how higher level users of totem/cpg break
when using the wrong types for their network data structures.

Further, I am of the opinion if these applications break because they
allow negative node ids in their data structures, they should be
repaired instead of hacking up corosync/openais/totem to support their
faulty declarations.

> > I really think the likelyhood of this patch ever being accepted is
> > pretty close to zero :)
> 
> I knew that before submitting.
> But I still felt obliged to do so.
> 
> Sorry for wasting your time.
> 
> >
> >
> > Regards,
> > -steve
> >
> > On Wed, 2008-08-20 at 10:10 +0200, Andrew Beekhof wrote:
> >> I'm sure this will be an unpopular patch, however there are good
> >> reasons for it.
> >>
> >> Although OpenAIS uses uint32_t for node ids, both the in-kernel and
> >> userspace pieces of the DLM use int32_t.
> >> I'm also told that the chances of the kernel pieces changing approach
> >> zero.
> >>
> >> So because the kernel is using signed ints, other pieces of the  
> >> RedHat
> >> stack also use signed ints, clusters are unlikely to span the entire
> >> ipv4 address space (thus making dups unlikely) and that nodeids can  
> >> be
> >> manually assigned even if a dup occurs... I propose the following
> >> patch that converts any negative nodeid back into a positive one.
> >>
> >> http://hg.clusterlabs.org/extra/openais/whitetank/raw-rev/ 
> >> b6a7886a3e90
> >>
> >> diff -r 70c18fd72ea9 -r b6a7886a3e90 exec/totemnet.c
> >> --- a/exec/totemnet.c	Thu Aug 14 07:31:36 2008 +0200
> >> +++ b/exec/totemnet.c	Mon Aug 18 12:17:10 2008 +0200
> >> @@ -702,7 +702,12 @@ static int netif_determine (
> >>  	 * field is only 32 bits.
> >>  	 */
> >>  	if (bound_to->family == AF_INET && bound_to->nodeid == 0) {
> >> -		memcpy (&bound_to->nodeid, bound_to->addr, sizeof (int));
> >> +		int nodeid = 0;
> >> +		memcpy (&nodeid, bound_to->addr, sizeof (int));
> >> +		if(nodeid < 0) {
> >> +		    nodeid = 0 - nodeid;
> >> +		}
> >> +		bound_to->nodeid = nodeid;
> >>  	}
> >>
> >>  	return (res);
> >>
> >> _______________________________________________
> >> Openais mailing list
> >> Openais at lists.linux-foundation.org
> >> https://lists.linux-foundation.org/mailman/listinfo/openais
> >
> 



More information about the Openais mailing list