David Teigland wrote: > 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? >
Ya. Every cpg handle will get that callback. And yes, normal cpg confchg callbacks are delivered before totem_confchg. >> 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 > Regards, Honza _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
