[checkmk-commits] 6969 FIX Fixed recurring flexible downtimes.

Module: check_mk Branch: master Commit: f7b6dcdd5dd3622bae05c7b7698772de5c53e165 URL: http://git.mathias-kettner.de/git/?p=check_mk.git;a=commit;h=f7b6dcdd5dd362… Author: Sven Panne <sp(a)mathias-kettner.de> Date: Fri Mar 22 12:05:21 2019 +0100 6969 FIX Fixed recurring flexible downtimes. Previously, the combination of "recurring" and "flexible" was broken for downtimes. The effect was that such downtimes remained hot even outside their intended time window, so that the next occurring problem just triggered the start of such a downtime and no problem was notified. An example for such a scenario: A flexible host downtime was configured to happen every day between 02:00 and 03:00 for 2 hours. Everything was OK between 02:00 and 03:00, but at 08:15 the host went DOWN. This started the downtime, lasting until 10:15, which is of course totally unintended: The problem did not happen between 02:00-03:00, so the downtime should not start and normal problem processing should be done, including notifications etc. This has been fixed, so the recurring flexible downtimes are working as intended now. If you update your installation, there is nothing more you have to do, all downtimes automatically work correctly after that. If you do not want to update yet, you should delete your recurring flexible downtimes for now and add new recurring fixed downtimes instead as a workaround until you update. Change-Id: I16a10a53882d5e9f4fec71ba8af3d5956742c819 --- .werks/6969 | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/.werks/6969 b/.werks/6969 new file mode 100644 index 0000000..c063aac --- /dev/null +++ b/.werks/6969 @@ -0,0 +1,27 @@ +Title: Fixed recurring flexible downtimes. +Level: 2 +Component: cmc +Compatible: compat +Edition: cee +Version: 1.6.0i1 +Date: 1553251801 +Class: fix + +Previously, the combination of "recurring" and "flexible" was broken for +downtimes. The effect was that such downtimes remained hot even outside +their intended time window, so that the next occurring problem just +triggered the start of such a downtime and no problem was notified. + +An example for such a scenario: A flexible host downtime was configured to +happen every day between 02:00 and 03:00 for 2 hours. Everything was OK +between 02:00 and 03:00, but at 08:15 the host went DOWN. This started the +downtime, lasting until 10:15, which is of course totally unintended: The +problem did not happen between 02:00-03:00, so the downtime should not start +and normal problem processing should be done, including notifications etc. + +This has been fixed, so the recurring flexible downtimes are working as +intended now. If you update your installation, there is nothing more you +have to do, all downtimes automatically work correctly after that. If you +do not want to update yet, you should delete your recurring flexible +downtimes for now and add new recurring fixed downtimes instead as a +workaround until you update.