Hi Cyrille, sure no problem, here it goes:
> Does I understand correctly your scenarii? > > >>> No alarm exist: Send event with reduction key and result should be *one* > >>> alarm > This is the usual workflow when no alarm already exist.Nothing to be changed > here correct > >>> One alarm with reduction key exist: Send event with matching reduction > >>> key and result should be *one* alarm > This is the usual workflow when an alarm already exists; That's, the alarm > gets updated with lasteventtime etc... Nothing to be changed here correct > >>> One alarm cleared exist: Send event with matching reduction key and > >>> result should be *one* alarm > I don't know what currently occurs in this case: > 1- Normally cleared alarms don't exist since they are automatically > vacuumd every 5 minutes. So, this situation can only exists within these 5 > minutes. > 2- In the event a matching event occurs during these 5 minutes, what > would happen to the alarm isn't clear for me: I think the event will update > the alarm but it's status will still stay as "cleared", and it will still be > vacuumed after 5 miutes. If this is really what happens, it is for me a bug, > because as the user has already cleared the alarm he isn't expecting any > further matching event, and thus any occurence of a matching event should > create a new alarm. Is it what you're trying to achieve? The default configuration of Vacuumd has a cron job and runs: - deletePastClearedAlarms (unasked alarms older than 5 minutes) - deleteAllPastClearedAlarms (unacked alarms older than 1 day) - garbageCollect (all alarms older than 3 days) - fullGarbageCollect (all alarms older than 8 days) If they are deleted Alarmd will create new alarms. It is then the first case "No alarm exist”. > >>> One alarm acknowledged exist: Send event with matching reduction key and > >>> result should be *one* alarm > I don't understand what you're expecting to happens here. > > For me, when I acknowledge an alarm this means I know there's an issue and > I'm working on it. And, I don't want to be bothered by openNMS relating this > issue anymore. > > So, I don't want OpenNMS to make this alarm outstanding again, I want it to > keep this alarm acknowledged.OpenNMS can update the alarm's lasteventime > etc... but it shall not make it outstanding. > > Is it also how you're expecting OpenNMS to behave? That’s the reason there should be *one* alarm in OpenNMS. You have it acknowledged, you know - any further alarm deduplicates the existing instance. It is the behavior you’ve described. > >>> One alarm acknowledged *and* cleared exist: Send event with matching > >>> reduction key and result should be *two* alarms > I don't understand what you're expecting to happens here neither. > > For me the fact that the alarm has been cleared means that the user isn't > expecting any new matching event anymore. So, in this case, a new alarm > should be created. > > Is it also how you're expecting OpenNMS to behave? correct > PS: Do you really think the code change is not complicated when your PR > modifies 1026 files?!? ;-p Something happened to the foundation-2016 branch. Thank you for the hint, this is not correct. Hope it helps. > 2015-12-17 1:20 GMT+01:00 <ro...@opennms.org <mailto:ro...@opennms.org>>: > Hello everyone, > > I’m working on the issue NMS-8011 [1]. The code change so far is not > complicated [2]. I’ve spent some time to figure out how to create a Unit test > for this behavior and dived into AlarmdIT [3]. > > The testPersistAlarm() [4] seems like has everything I need to create a test. > Try to understand the code in the integration test. Instead of dealing with > native SQL statements, I thought using the existing Alarm Data Access Object > (AlarmDaoHibernate) [5] has just get() and find() methods. > > Investigating some more, I’ve found a AlarmPersisterImpl() [6] which has a > persist() method but takes Events. It seems the method does not just persist > an Alarm it just forwards the Event to addOrReduceEventsAsAlarm() and > struggled to get the following test scenario implemented: > > - No alarm exist: Send event with reduction key and result should be *one* > alarm > - One alarm with reduction key exist: Send event with matching reduction key > and result should be *one* alarm > - One alarm cleared exist: Send event with matching reduction key and result > should be *one* alarm > - One alarm acknowledged exist: Send event with matching reduction key and > result should be *one* alarm > - One alarm acknowledged *and* cleared exist: Send event with matching > reduction key and result should be *two* alarms > > Any hints welcome and thank you in advance. > > [1] http://issues.opennms.org/browse/NMS-8011 > <http://issues.opennms.org/browse/NMS-8011> > [2] https://github.com/OpenNMS/opennms/pull/519 > <https://github.com/OpenNMS/opennms/pull/519> > [3] > https://github.com/OpenNMS/opennms/blob/develop/opennms-alarms/daemon/src/test/java/org/opennms/netmgt/alarmd/AlarmdIT.java > > <https://github.com/OpenNMS/opennms/blob/develop/opennms-alarms/daemon/src/test/java/org/opennms/netmgt/alarmd/AlarmdIT.java> > [4] > https://github.com/OpenNMS/opennms/blob/develop/opennms-alarms/daemon/src/test/java/org/opennms/netmgt/alarmd/AlarmdIT.java#L181 > > <https://github.com/OpenNMS/opennms/blob/develop/opennms-alarms/daemon/src/test/java/org/opennms/netmgt/alarmd/AlarmdIT.java#L181> > [5] > https://github.com/OpenNMS/opennms/blob/develop/opennms-dao/src/main/java/org/opennms/netmgt/dao/hibernate/AlarmDaoHibernate.java > > <https://github.com/OpenNMS/opennms/blob/develop/opennms-dao/src/main/java/org/opennms/netmgt/dao/hibernate/AlarmDaoHibernate.java> > [6] > https://github.com/OpenNMS/opennms/blob/develop/opennms-alarms/daemon/src/main/java/org/opennms/netmgt/alarmd/AlarmPersisterImpl.java > > <https://github.com/OpenNMS/opennms/blob/develop/opennms-alarms/daemon/src/main/java/org/opennms/netmgt/alarmd/AlarmPersisterImpl.java> > > -- > Ronny Trommer, OGP > Germany :: Fulda :: Stuttgart > Web: http://www.opennms.org <http://www.opennms.org/> > > PGP Key Fingerprint: 4A1B 4D06 FEEC 244D 38EF 8074 9075 B2E5 08A2 451E > PGP Key Server1: https://keyserver.pgp.com <https://keyserver.pgp.com/> > PGP Key Server2: http://pgp.mit.edu/ <http://pgp.mit.edu/> > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://www.opennms.org/index.php/Mailing_List_FAQ > <http://www.opennms.org/index.php/Mailing_List_FAQ> > > opennms-devel mailing list > > To *unsubscribe* or change your subscription options, see the bottom of this > page: > https://lists.sourceforge.net/lists/listinfo/opennms-devel > <https://lists.sourceforge.net/lists/listinfo/opennms-devel> > > ------------------------------------------------------------------------------ > _______________________________________________ > Please read the OpenNMS Mailing List FAQ: > http://www.opennms.org/index.php/Mailing_List_FAQ > > opennms-devel mailing list > > To *unsubscribe* or change your subscription options, see the bottom of this > page: > https://lists.sourceforge.net/lists/listinfo/opennms-devel
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------
_______________________________________________ Please read the OpenNMS Mailing List FAQ: http://www.opennms.org/index.php/Mailing_List_FAQ opennms-devel mailing list To *unsubscribe* or change your subscription options, see the bottom of this page: https://lists.sourceforge.net/lists/listinfo/opennms-devel
