[Openais] Proposed change to default nodeid generation

[Joel Becker]

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

-- 

"Too much walking shoes worn thin.
 Too much trippin' and my soul's worn thin.
 Time to catch a ride it leaves today
 Her name is what it means.
 Too much walking shoes worn thin."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127