Hi, We would like to be notified when a ring gets down or up to let them know when they need to check and repair which the network interfaces. The notification should be sent via SNMP traps to co-operate with various kinds of NMSs.
A proposed implementation was included in the patch posted at March 2010 by Sato Yuki-san: https://lists.linux-foundation.org/pipermail/openais/2010-March/014036.html The following MIB item in the patch is related to this. +corosyncNoticeIfaceEntry ::= SEQUENCE { + corosyncNoticeIfaceIndex INTEGER, + corosyncNoticeIface OCTET STRING, + corosyncNoticeIfaceStatus OCTET STRING +} The notification should be sent when; 1) when one ring detect a failure (get in FAULTY state) 2) when the failed ring get recovered. 3) when the second (last) ring also detect a failure and no longer usable to communicate with others 3) when the second ring get recovered. It is also preferable that the current status can be checked by some command line tools or an user-customized service plug-in. The proposed patch above tried to store the status into the objdb to achieve this but the implementation details does not matter. It would be glad if you would be considering it. Regards, Keisuke MORI 2011/7/22 Steven Dake <[email protected]>: > The Corosync flatiron 1.y series had many more features added then I > would have liked, but the development team feels the 1.y series > addresses any major gaps users of the software have had. As a result, > we are freezing any future feature development of the flatiron branch > permanently. We will continue to maintain z streams (1.4.z) bug fixes > for many years to come in a robust and aggressive fashion. > > Now that the flatiron chapter of Corosync is finished, we can move on to > new r&d work around Corosync 2.0. There are a few RFEs floating around > in bugzilla and the TODO list. This is your chance to provide feedback > about feature development you would like to see in Corosync. > > The overall theme for Corosync 2.0 is focused around trimming the fat > and simplifying the implementation without major performance regressions. > > The developers will take feature submission suggestions until Aug 31, at > which point we will prioritize features for 2.0 and close feature > submission requests. > > Regards > -steve > _______________________________________________ > Openais mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/openais > -- Keisuke MORI _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
