On 08/31/2011 12:37 AM, Keisuke MORI wrote: > 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. >
Yup this seems reasonable. The way that data comes out now is through corosync-notifyd vs a direct snmp integration into the corosync process. As a result, the linked patch needs to be changed to match the new model. Regards -steve > 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 >> > > > _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
