David,
> On Mon, Feb 22, 2010 at 06:00:21PM +0100, Jan Friesse wrote:
>> +struct cpg_ring_id {
>> + uint32_t nodeid;
>> + uint64_t seq;
>> +};
>
> What do you think about combining this patch with the other patch that
> adds cpg_ringid_get()? It's troublesome to combine the two patches to
> test.
>
That patch I sent was really incorrect. And I'm really not sure, what is
correct expected result.
I'll give you example.
Let's say, you have 3 nodes (a,b,c). B,C are joined in group EXAMPLE.
Now, A will fall ... you will not get normal confchg, because A was not
in group. Now on B, you will run new cpg process joined to group. If you
will call cpg_ringid_get, you will get different result, then before A fall.
So, main question is, WHEN ringid should change? From my point of view
(because CPG is lightweight membership), it should change when group
change. But group change doesn't mean totem membership change (both case
can really happen. Group change without Totem membership change and
Totem membership change without group change). Of course, if we rely on
group change, totem ringid really doesn't make sense no longer. If we
rely only on Totem membership change, we need something like I
implemented in cpg_totem_confchg.
>> +typedef void (*cpg_totem_confchg_fn_t) (
>> + cpg_handle_t handle,
>> + struct cpg_ring_id ring_id,
>> + uint32_t member_list_entries,
>> + const uint32_t *member_list);
>
> I've started working on the code to use this, and it might be nice if the
> parameters matched the normal confchg parameters as closely as possible,
> i.e. include cpg_name, and use cpg_address instead of uint32_t.
I was thinking about that, but:
- cpg_name of what? We are talking about Totem membership change. Totem
doesn't know anything about groups. If you want group_name of
pid/nodeid/group unique triple, it can be implemented, but ... can you
feel it doesn't fit very well?
- cpg_address looks like this:
struct cpg_address {
uint32_t nodeid;
uint32_t pid;
uint32_t reason;
};
Only thing from that structure which is used in Totem membership change
is nodeid (what we are returning currently. True is that
member_list_entries is really not good name and should be something like
node_list_entries).
- What should be filled in pid? Totem doesn't know about client pids.
- Very similar is reason field. I can imagine to return only
CPG_REASON_NODEDOWN and/or CPG_REASON_NODEUP.
Regards,
Honza
_______________________________________________
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
