I'll respond to all of the recent comments on this thread here.
First, for Tarus, my summary of the use case is that the client wants to
notify on all events, minus a few specific events they don't care about.
So, they effectively want an exclusion list not an inclusion list. I
can easily extend the work that I've done to support an exclusion list,
for example:
<notueis>
<uei>foo</uei>
<uei>bar</uei>
</notueis>
I'll also point out that I'm suggesting backing out the "notify=false"
event code only once a suitable replacement for that functionality is
available, and not before.
Tarus, what do you think?
Regarding merging the changes I'm suggesting above, 1.8 is probably the
right place for all of the reasons folks have mentioned, unless the
changes stay small and we review it and test it. I'd love to see 1.8
come out soon enough that we wouldn't even consider backporting this to
1.6. :-)
David, regarding the service matching, I am aware of it as one of the
many things you can match on with filters, and that it is also the one
specific type of rule matching that the wizard in the webUI helps you
out with. You can still do that with filters with the new code, and in
fact, that is still the only way you can do service matching on
notifications. The default rule for the webUI would be changed to be
empty, and no rule would be added to the config file in this case. If
you select services to match (include or exclude), then a rule would be
generated, but it would just be "isHTTP" or whatever and not the odd
"isHTTP && ipaddr != '0.0.0.0'" type of rule that we have today. :-)
Lastly, I would love to see notifications eventually based on alarms.
+1 +1 +1!!!!!! I've been slowly cleaning up notifd over time to help
make that easier when we get there. :-)
- djg
On Tue, 11 Nov 2008 08:37:55 -0500, "Tarus Balog" <[EMAIL PROTECTED]>
said:I
>
> 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
-------------------------------------------------------------------------
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
