Hello Ronny,
I'm sorry I can't follow you: I don't understand the scenarii, and, as I'd
really like to have a good alarm workflow, I would like to make sure you're
going in the good direction for (the selfish) me.
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
>>> 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
>>> 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?
>>> 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?
>>> 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?
I hope you can understand my question despite my bad english, and that my
question aren't too irrelevant.
Cheers,
Cyrille
PS: Do you really think the code change is not complicated when your PR
modifies 1026 files?!? ;-p
2015-12-17 1:20 GMT+01:00 <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
> [2] 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
> [4]
> 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
> [6]
> 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
>
> PGP Key Fingerprint: 4A1B 4D06 FEEC 244D 38EF 8074 9075 B2E5 08A2 451E
> PGP Key Server1: https://keyserver.pgp.com
> PGP Key Server2: http://pgp.mit.edu/
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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
>
------------------------------------------------------------------------------
_______________________________________________
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
