[checkmk-commits] 5477 Rule-based recurring downtimes can have and end now.

Module: check_mk Branch: master Commit: 33216e7e4261f9805f05b408cdd59e17f2ebbca6 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=33216e7e4261f9… Author: Sven Panne <sp(a)mathias-kettner.de> Date: Wed Jan 10 14:14:29 2018 +0100 5477 Rule-based recurring downtimes can have and end now. Prevously, you could only specify a point in time when a rule-based recurring downtime starts. You can now optionally specify an additional point in time when no new downtimes will be started for such a rule, i.e. effectively disabling that rule from that point onwards. Note that specifying such an end point is not possible for ad-hoc downtimes, i.e. the ones entered directly without rules. This is caused by the underlying Nagios-compatible external commands which don't know such a field. Simply extending the commands by adding such a field is not a reliable option: In multi-site environments you can have a mix of monitoring cores and don't know which site uses which core. Change-Id: I37a4e2d280da782d42e1b3ebabb1836c1cd70fa4 --- .werks/5477 | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/.werks/5477 b/.werks/5477 new file mode 100644 index 0000000..66c122d --- /dev/null +++ b/.werks/5477 @@ -0,0 +1,20 @@ +Title: Rule-based recurring downtimes can have and end now. +Level: 1 +Component: core +Compatible: compat +Edition: cee +Version: 1.5.0i3 +Date: 1515590636 +Class: feature + +Prevously, you could only specify a point in time when a rule-based +recurring downtime starts. You can now optionally specify an additional +point in time when no new downtimes will be started for such a rule, i.e. +effectively disabling that rule from that point onwards. + +Note that specifying such an end point is not possible for ad-hoc downtimes, +i.e. the ones entered directly without rules. This is caused by the +underlying Nagios-compatible external commands which don't know such a +field. Simply extending the commands by adding such a field is not a +reliable option: In multi-site environments you can have a mix of monitoring +cores and don't know which site uses which core.