[Openais] Proposed change to default nodeid generation

Steven Dake sdake at redhat.com
Thu Aug 21 11:15:14 PDT 2008


On Thu, 2008-08-21 at 10:31 -0700, Joel Becker wrote:
> On Thu, Aug 21, 2008 at 08:24:35AM +0200, Andrew Beekhof wrote:
> > Right.  Although we may have to tell users not to use it  
> > (autogeneration)
> > since the the values it generates aren't supported by the rest of the
> > RedHat's stack - particularly the kernel portion.
> 
> 	Right.  Currently the cman stack makes the users hand-specify
> node numbers.  I think they would want to use autogeneration too, but
> they can't right now.
> 
> >> because his software uses the autogeneration.
> >
> > Not so much "uses" as "lets openais do its thing because its none of our 
> > business" :-)
> 
> 	Well, sure.  Some people do like specific node numbers - it
> helps you identify which node is failing, etc - but many environments
> don't need that.  Especially if we build tools that allow us to identify
> nodes specifically without the node numbers.
> 
> >> 	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.
> >
> > Right.  Pacemaker has such functions but they all use uint32_t.
> 
> 	I guess my question was: do they use cpg to find out the
> information, or do they ask the corosync daemon?  I'm betting those
> functions don't use cpg, and thus wouldn't be fooled by a cpg hack.
> 
> >> 	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.
> >
> > That feels like a layering violation to me.
> >
> > It's not a cluster manager's business to dictate nodeids to the
> > infrastructure layer, it should be telling us (as it does now).
> 
> 	It *is* a layering violation.  No argument here.  However, it
> gives us a flexible way for corosync plugins that want to support fs/dlm
> to provide fs/dlm-safe nodeids without modifying the defaults in
> corosync.  No corosync code would have to change other than the
> auto-nodeid code going "if plugin->auto { nodeid = plugin->auto() } else
> { nodeid = generic_auto() }".
> 
> > It also presents problems when/if different pieces want to use
> > different allocation schemes.
> 
> 	But you wouldn't be in those places.  If you want to use fs/dlm,
> you have to have this set of nodeids.  If you don't, you don't.  You
> can't interact between the two sets anyway, because the non-fs/dlm-safe
> ids can't use fs/dlm.
> 
> Joel

I may be dense, but I am still not sure what you are proposing.  It
sounds like you would like a function added to the service engine
structure which allows the setting of the nodeid for that local node.

This approach has several issues:
1) If two service engines define this function, which one gets to set
the node id?  Both?  Then *two* sets of nodeids have to be transmitted
across the network.
2) the Node id must be transmitted over the network for deliver to a
variety of plugin functions in the service engines.  How do old daemons
and new daemons interact?  Keep in mind, nodeids are used to make
decisions about correctness in the service engines currently.
3) A service engine can already set the node id statically in the
configuration object database.  Why not just do it that way?

Regards
-steve



More information about the Openais mailing list