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: [EMAIL PROTECTED]
Phone: (650) 506-8127
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
