On Mon, 2009-08-31 at 15:44 -0500, David Teigland wrote: > Here are two related and troublesome problems that would be nice to fix, > probably in future versions -- they probably can't be fixed maintaining > existing apis and protocols (although adding new api's to help with them might > be nice if possible). > > 1. correlating events from different services locally > > I get nodedown from both cman (or quorum service) and cpg. I need to > correlate them with each other. When I get a cpg nodedown for node A, I don't > know which cman nodedown for A it refers to: one of multiple in the past or > one in the future that cman hasn't reported yet. >
Correlation could be solved by addition of api to cman, cpg, and quorum to retrieve the globally unique ring id for the last configuration change delivered to the application. If you agree, we can work on the implementation for corosync 1.1. Adding this to CPG is trivial, not sure about other services. Our policies wrt x.y.z would not be violated with this change. As an example, the API for cpg might look like cpg_ringid_get (handle, &ring_id); Then ring_id could be memcmp'ed in the application. This would retrieve the last ring id delivered to the application (not the current ring id known to the cpg service). > 2. correlating events among nodes > > Some kind of global event/generation id associated with each configuration > that nodes can use to refer to the same event. (For extra credit, make this > useful to detect the first configuration of a cpg across the cluster.) > define event here, you mean configuration change event or message delivery event? > Dave Regards -steve > > _______________________________________________ > Openais mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
