Fix notification counters, again
commit538862ee33fcaca43b876a616a988ebba11ce77a
authorRobin Sonefors <robin.sonefors@op5.com>
Thu, 26 Jun 2014 14:05:25 +0000 (26 16:05 +0200)
committerRobin Sonefors <robin.sonefors@op5.com>
Thu, 26 Jun 2014 15:17:07 +0000 (26 17:17 +0200)
treee59c8db42f08fe8129349bf37bf2acbb24d57766
parentcc045cc1addc293f3c38382d96700f1ea79db032
Fix notification counters, again

In ac4ec42, I claimed that the wrong hook was enabled. Turns out, it
wasn't the necessarily "wrong", just not correctly hooked up everywhere
on the receiving end, would have triggered deluges of duplicate entries
in the notification table, and just overall triggered a lot of
unnecessary bandwidth use.

Instead, move all of this notification handling code to the regular
notification hook. It's triggered much less frequently, and is made for
this very thing.

The old code also cheated with respect to last_notification and
next_notification. Not a disaster, but when you're trying to verify that
they're in sync, it is distracting if they're not - and the cheating
*did* become disastrous when we reacted to the per-contact hook rather
than the per-notification.

This also fixes a bug, where we tried to only react to normal
notifications but implemented the check against the wrong struct member.
I think this was really bad for host notifications, but I deleted the
code instead of examining exactly how it was broken: we don't only want
to react only to normal notifications, we want to be in sync, goddamit!

Finally, as pointed out in bug #8668, no_more_notifications is sometimes
set by nagios when notifying, and hence it needs to be transmitted as
well.

Change-Id: Ifd417e16410cacdea80f8a9ade594790253e7954
Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
hooks.c
module.c