Re: [opennms-devel] Notification commands and paths

[David H. <da...@op...>]

On Jul 28, 2005, at 5:20 AM, Stanislav Sinyagin wrote:

> David, would it be useful if I propose the new design for the  
> notifications
> engine?

Sure.  Please provide a use case(s) the supports the redesign.  So  
that we can write unit tests that fail with the current design/code  
and pass with the new design/code.

> It would become incompatible with existing configs, so we'll need
> XSLT temmplates to transform old configs to the new design.

Often, enhancements to our code include configuration changes.  We've  
never provided this mechanism before, but that sounds like a good  
strategy.

> I can propose the new data structures, but not sure if I'm able to
> implement them in java, although I'd try.

Okay.  We're willing to help out on this list and other forums as  
well.  There may be others on this list that have some time to  
contribute to the actual coding, however, I'm currently covered up  
with a couple of other enhancements/bugs.

> The goal of the design would be modular and extendable configuration,
> with none or minimum hardcoded information, so that the users could
> set up their notification strategy as flexible as possible.

Please take into account that in the current development branch, 1.3,  
there has been a new enhancement made we call "Roles".

So the toughest part that you are facing, we face everyday as we work  
on the code, is that you will have to:

1) Make sure that the current JUnit test cases continue to pass as  
you modify the code
2) Investigate the code to determine the requirements that current  
code delivers.  Sorry, we don't have any requirements document that  
drove the original design of what we currently have.

While we believe there are some serious implementation problems with  
respect the the notification code itself, we have rarely came across  
a more flexible and extensible notification system.  The current  
enhancements that I have scheduled for the notification system is a  
feedback/acknowledgment process.


Use case:

OpenNMS user receives a notification.
User acknowledges the notification from the same protocol/system that  
provided the notification to stop/cause an escalation.

Example:
I receive a Jabber IM that a service is down.  Based on my reply to  
that IM, OpenNMS will either:

     1) Acknowledge the notification and the alarm/event.
     2) Immediately escalate the notification.
     3) Suppress the notification/alarm for a specified amount of  
time. (Suppression is an up coming new feature)

Thanks for your help,

David Hustace
The OpenNMS Group, Inc.
http://www.opennms.com