On Nov 10, 2008, at 8:04 PM, DJ Gregor wrote:
> Tarus, if I could implement the changes that I suggest, could I back-
> out
> the eventd/notification changes you made today? Would you like to see
> this in 1.6.x (if so, what's your timeframe?), or should it wait for
> 1.8?
Okay, here is the problem I'm trying to solve for a client.
They want to send almost every single event from OpenNMS to their
ticketing system. The manager is worried about missing important
events, so they want to make sure that every event possible is sent.
So they have a script that goes through eventconf.xml and all the
include files and generates a notifications.xml file with thousands of
events.
Now certain events, such as RTC logins, etc., they don't care about,
so they turn those off.
The problem is they want to divide the events into six groups. They
are an online gaming company and each group would represent a
different game. The problem is that this will multiply by six the
amount of notifications they have to maintain.
I suggested they use the MATCH-ANY-UEI event. This works for them, but
there is no way to turn off the events they no longer care about. The
number of events they wish to ignore is small, less than 10, but they
tend to be very numerous.
So I thought that a simple and easy way to correct this would be just
add an attribute that would flag whether or not the notice should be
sent for that event. I like it for two reasons. First, it is simple.
It is basically a single if statement. Second, it's safe. It changes
nothing for a normal user.
Now the client can set up six MATCH-ANY-UEI events, set notify=false
for those events they wish to ignore, reload eventd with the new
"reload" event and they are golden. They have just reduced their
configuration effort by at least two orders of magnitude.
I don't think your solution provides quite the level of simplicity or
safety. It contains great features, don't get me wrong, but I think it
would still require more maintenance.
I would prefer it if my solution wasn't backed out, because then I
would need to maintain a separate release for this client. I don't
believe it really hurts anything.
As I mentioned, your changes are excellent. For most of our users I
think they will like them. However, I'd like to see them in 1.8 versus
1.6. I really don't like touching stable code if at all possible, with
exceptions for features that either stand alone or have viable
workarounds (such as a GUI editor for a config file - if it borks the
user can always edit the config file by hand).
Which brings me to another topic. I want to move notifications to be
based on alarms instead of events. I'm interested in ideas on how to
implement and improve this. I'm thinking some sort of command in the
automations to generate a notice (or send the alarm to notifd) when
the alarm is first raised, as well as being able to send a true
resolved event ("Node is Up" vs. "RESOLVED: Node is Down"). This would
allow us to remove the code from notifd that does this for the basic
OpenNMS events.
But is this something we could do in 1.8 or should we wait to 1.10?
With the major capsd work that Matt is doing right now, I'm thinking
1.10 for notifications. Thus we could put your changes into 1.8 to
give people a greater flexibility with the current notifd and set our
sites on alarms for 1.10.
Comments?
-T
_______________________________________________________________________
Tarus Balog, OpenNMS Maintainer Main: +1 919 533 0160
The OpenNMS Group, Inc. Fax: +1 503 961 7746
Email: [EMAIL PROTECTED] URL: http://www.opennms.org
PGP Key Fingerprint: 8945 8521 9771 FEC9 5481 512B FECA 11D2 FD82 B45C
-------------------------------------------------------------------------
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
