On Tue, Mar 02, 2010 at 11:10:49AM +0100, Jan Friesse wrote: > 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.
The existing totem ring id already has a defined behavior, and I wasn't expecting anything beyond that. i.e. cpg_ringid_get would not tell us anything new about cpg memb changes, only abut totem changes. So, when a totem memb change caused a cpg memb change, then it would be useful. But, it's not really necessary to have this with your other patch, so let's just leave out the cpg_ringid_get. > > 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? OK, it's probably not necessary. Is there a totem confchg callback per handle then? And I still get all normal cpg confchg callbacks before the totem_confchg callback? > 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. Ah, right, I'd not considered that. It's probably better to keep them nodeids then. > - Very similar is reason field. I can imagine to return only > CPG_REASON_NODEDOWN and/or CPG_REASON_NODEUP. I don't expect I'll need reason. Thanks, Dave _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
