[dev.icinga.com #4908] Extending Service/Host Acknowledge with expiration date

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/4908

Created by dlinde on 2013-10-17 17:38:09 +00:00

Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2015-05-18 12:17:53 +00:00 (in Redmine)

---

Say a service/host is in anything but an OK state and has one acknowledgment with an expiration date sometime in the future. This one acknowledgment works fine, notifications are suppressed and the ack retires if its time is expired.

However, if a user comes in between when that first ack was introduced and when it expires and tries to extend the expiration date by appending a new ack with a later expire time, that new ack is ignored and the service/host loses its ack according to the first expiration date.

It works if the user takes an extra step to remove the first ack before introducing the second, but it seems intuitive to have the functionality to extend the expire time by appending the second ack to the first.

Changesets

2015-02-15 00:25:43 +00:00 by mfriedrich a5d0469

Fix cmd.cgi use_ack_end_time param does not enable tickbox in form

fixes #8445
refs #4908

2015-02-15 01:03:39 +00:00 by mfriedrich b143826

Core/Classic UI: Allow to extend expire time for acknowledgements

If the problem was acknowledged and an expire time was set,
check if the newly provided expire time is greater than the old
one. If so, remove the old acknowledgement and create a new one.

The Classic UI shows a new command if the problem has been acknowledged,
additional to the already existing removal command.

Requires the patch in #8445

refs #4908

---

Relations:

• relates #8445

[icinga-migration]

Updated by mfriedrich on 2013-10-17 17:44:33 +00:00

• Tracker changed from Bug to Feature
• Priority changed from Low to Normal

same 'problem' with downtimes. that's why they may 'overlap' (at least docs say so).

for me that's a feature, not a bug. the core should first delete the acknowledgement internally and then re-create it which requires extensive testing once someone created a patch for it. or reschedule the expire event.

for downtimes this more of a problem with the id itsself handled on updates.

[icinga-migration]

Updated by mfriedrich on 2014-03-12 22:33:56 +00:00

• Category set to Acknowledgements
• Status changed from New to Assigned
• Assigned to set to ricardo
• Target Version set to 1.12

[icinga-migration]

Updated by mfriedrich on 2014-12-08 08:54:26 +00:00

• Target Version changed from 1.12 to 1.12.1

[icinga-migration]

Updated by mfriedrich on 2014-12-08 09:06:50 +00:00

• Target Version changed from 1.12.1 to 1.13

[icinga-migration]

Updated by mfriedrich on 2015-02-15 00:24:18 +00:00

• Relates set to 8445

[icinga-migration]

Updated by mfriedrich on 2015-02-15 00:38:05 +00:00

• Assigned to changed from ricardo to mfriedrich

I'm not sure what happens when someone acknowledges a host or service multiple times (the problem acknowledgement is only one item, but the comments are additive). That state is undefined and the core leaves that to your own imagination (multiple comments are not prevented).

By allowing one to extend the expire time by sending a new acknowledgement with an end_time in the future (greater than already set) and having the problem acknowledged already this works by removing the acknowledgement first, and then setting a new one. Removing an acknowledgement also causes the removal of the scheduled expire event which is what we expect in the first place. Though its easier to remove the acknowledgement (and all comments) and re-add a new one. That way the extended expiry is still treated as new acknowledgement and external interfaces may trigger this more transparently.

Regarding the Classic UI this is a little bit problematic, but there needs to be an additional field to be shown once the host/service is in a problem state and if the problem has been acknowledged. Instead of only showing the removal command item, we'll also add a command for extending the expire time, which sets the 'use_ack_end_time' for cmd.cgi and opens the expiration date field by default (see fix in #8445). Once the "updated" acknowledgement is processed, the expire time is visible in the newly created acknowledgement comment.

Imho this sounds reasonable, and is also backwards compatible. Though I'm not sure how and if this can be implemented in Icinga Web 1.x and 2.x.

[icinga-migration]

Updated by mfriedrich on 2015-02-15 01:04:49 +00:00

• Status changed from Assigned to New
• Assigned to deleted mfriedrich
• Target Version changed from 1.13 to Backlog

Though, I am not convinced if this is really the best idea or implementation. I'm leaving this inside a feature branch.

[icinga-migration]

Updated by mfriedrich on 2015-05-01 10:59:43 +00:00

• Target Version deleted Backlog

[icinga-migration]

Updated by berk on 2015-05-18 12:17:53 +00:00

• Target Version set to Backlog