On Mon, Aug 31, 2009 at 02:28:33PM -0700, Steven Dake wrote: > 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).
Turns out that libcman already has a call that returns the ring id, so all I need now is the addition to cpg. Dave _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
