Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #905] add a command to disable notifications program-wide with expire time as scheduled event; classic ui & idoutils reflected #415
This issue has been migrated from Redmine: https://dev.icinga.com/issues/905
Created by rbrinkmo on 2010-10-15 13:46:19 +00:00
2012-07-30 20:19:26 +00:00 by mfriedrich 5b4e773
2012-08-25 13:22:26 +00:00 by mfriedrich 54b8eff
2012-08-25 23:47:53 +00:00 by mfriedrich 4468b25
Updated by ricardo on 2010-11-05 11:36:20 +00:00
I don't think that this will break the NEB as well.
cause it will be 2 seperated commands.
The ones witch have comments allready, stay as they are. The one's with new, forced comments get submitted as usual and an additional comment command (sounds funny) will be submitted on top of it.
Updated by mfriedrich on 2011-06-26 15:56:16 +00:00
the question which comes to mind is - this should only be a timely limited command replacement for disable notifications on hosts/services, but by adding another end_time then.
wouldn't it be more sufficient to schedule a downtime, supressing the notifications either way? having set the duration (flexible) and start/endtime (fixed) this would allow basically the same goal to be reached, don't you think?
Updated by rbrinkmo on 2011-07-26 15:38:05 +00:00
A scheduled downtime has a different meaning in our SLA reporting. It is like a maintenance (the host/service don't have to be available). That's the reason why we need a different function just to disable the notification for a defined time for those hosts and services which should be available from the view of SLA Reporting.
It would be great if this information also would be available in the idodb.
Updated by mfriedrich on 2012-07-30 15:53:22 +00:00
i don't think this should be done on a host or service basis, but globally for all notifications, as we can re-use inner core functionality on this.
this requires the following changes
what's not possible
might require more tests and bugfixes for now
Updated by mfriedrich on 2012-07-30 16:36:25 +00:00
the ENABLE_NOTIFICATIONS command should possibly clear
question remains - how to get the timed_event for that given type and time in order to safely delete it? the event itsself should only happen if the time is not cleared before.
Updated by mfriedrich on 2012-07-30 19:30:22 +00:00
there might be a race condition on
this can be resolved on checking if the expire_time > event_time->run_time, only letting valid expiry times but not cleaning those in the future.
see the test below, which shows 2 events, but only the last one actually happens.
showing that the single one works as well with those adaptions.
Updated by mfriedrich on 2012-07-30 19:54:03 +00:00
Updated by mfriedrich on 2012-07-30 19:59:11 +00:00
hm, i see this was not the original feature request. misread that. follow the host/service notification expiry and discussion on #2919 (with #2473 and #2474 i do not think that this will be necessary, if you can see that someone disabled notifications on a host or service, even a reset button is there already).