Based on Tarus mentioning a few weeks back that he has a need to be able
to have one notification that matches large number of UEIs, I've started
some work on notification configuration in this direction. I have the
changes completely done in the daemon, I just need to add the necessary
support to the webUI for editing notifications. Before I finish this up
and commit it, I want a sanity check to make sure that this is a good,
committable solution.
_Where we are today_
Right now, each configured notification can match exactly one UEI, like
this:
<uei>uei.opennms.org/internal/discovery/newSuspect</uei>
Actually, that's a bit of a lie: the UEI can be "MATCH-ANY-UEI" and it
will match all UEIs (you can also do regexps...). But, no matter what,
the <uei> tag is still required, and there can be only one.
Furthermore, each notification today must have exactly one filtering
rule, like this:
<rule>IPADDR != '0.0.0.0'</rule>
This is the case even when the filtering rule makes no sense for a
certain event and could never possibly match. An example is our
newSuspect event which has an interface, but since this is a *new*
suspect, there is no information in the database, so the filter cannot
possibly match. There are some hacks to make this work, I don't like
them one bit, and I would like to see them go away. :-)
_Where I want to go_
1. Allow multiple UEIs to be specified for a single notification.
2. Make the filtering rule optional and simplify notification matching
in the daemon.
3. Eliminate special cases in the UEI configuration (MATCH-ANY-UEI, "~"
prefix regex matching) and replace with "real" object features to
represent them, i.e.: XML elements.
#1 is easy. Backward compatible. If you want to specify multiple UEIs,
instead of using <uei>uei</uei>, you use
<ueis><uei>uei1</uei><uei>uei2</uei></ueis>. This will be invisible in
the GUI--you just select the UEIs you want.
#2 is easy. One change will be required: events that don't have any
data that can be filtered on will need to have their <rule> removed.
E.g.: newSuspect events. For the shipped default notification configs,
we'll remove the useless "ipaddr != '0.0.0.0'" rule, and make the webUI
not have a rule by default.
#3 is easy. Changes will be required if users are using the
special-case UEI features. In this case, they will either have to
switch to a new XML element like <match-any-uei/> or tag their UEI
elements as regexp matches, e.g.: <uei
matchType="regexp">uei.opennms.org/.*</uei>.
I have the daemon components of #1 and #2 done, and the daemon component
of #3 will be easy. The webUI work shouldn't take too much effort, as
well, just some focused time.
What do you think?
- djg
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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
