[dev.icinga.com #11423] Cleanup downtimes created by ScheduleDowntime

[icinga-migration]

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

Created by mfrosch on 2016-03-21 08:16:39 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2016-08-13 13:25:04 +00:00)
Target Version: 2.5.0
Last Update: 2016-11-09 14:58:52 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

---

Should we cleanup downtimes that were generated by a ScheduledDowntime apply, when the apply does no longer exist?

Attachments

• 11423_scheduled_downtime_there.png mfriedrich - 2016-08-13 13:15:31 +00:00
• 11423_scheduled_downtime_removed.png mfriedrich - 2016-08-13 13:15:45 +00:00

Changesets

2016-08-13 13:18:50 +00:00 by mfriedrich 8f03adf

Remove Downtime objects w/o reference to ScheduledDowntime objects

fixes #11423

2016-08-13 19:43:59 +00:00 by gbeutner 9f8cb8d

Clean up the code a bit

refs #11423

---

Relations:

• relates #11422
• relates #11423
• duplicates #11423

[icinga-migration]

Updated by mfrosch on 2016-03-21 08:16:54 +00:00

• Relates set to 11422

[icinga-migration]

Updated by mfriedrich on 2016-03-31 10:02:18 +00:00

• Category changed from Checker to libicinga
• Priority changed from Normal to Low
• Target Version set to Backlog

[icinga-migration]

Updated by mfriedrich on 2016-04-19 09:58:44 +00:00

• Duplicated set to 11608

[icinga-migration]

Updated by mfriedrich on 2016-04-19 09:59:58 +00:00

• Parent Id set to 11312

[icinga-migration]

Updated by mfriedrich on 2016-05-02 13:36:38 +00:00

Traverse the question into "when the config owner (=ScheduledDowntime object) does not exist anymore".

[icinga-migration]

Updated by mfriedrich on 2016-08-08 14:10:40 +00:00

• Relates set to 12317

[icinga-migration]

Updated by mfriedrich on 2016-08-08 14:13:43 +00:00

• Priority changed from Low to Normal

• config_owner
• scheduled_by

[icinga-migration]

Updated by ronator on 2016-08-11 09:34:30 +00:00

This bug is really annoying.

[icinga-migration]

Updated by mfriedrich on 2016-08-13 13:21:09 +00:00

• File added 11423_scheduled_downtime_there.png
• File added 11423_scheduled_downtime_removed.png
• Status changed from New to Assigned
• Assigned to set to mfriedrich
• Target Version changed from Backlog to 2.5.0

Your comment isn't helpful at all.

Detecting this sort of deletion isn't as easy as it sounds. We'll have to wait until the downtime is fully loaded to check against the config_owner attribute and its reference to an actual ScheduledDowntime object. Such a thing could happen inside the expire handler for downtimes - mainly for the reason that ScheduledDowntime objects may also be created at runtime without any restart. Doing that inside Start() (calling Stop()) would lock.

The thing I don't like about my patch is that the expire interval is 60s which might just take a minute to see the change reflected in DB IDO and Icinga Web 2. Although until no-one comes up with a better one, I'll leave the fix as is. Make sure to fetch the snapshot packages and properly test the patch.

[icinga-migration]

Updated by mfriedrich on 2016-08-13 13:25:05 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

Applied in changeset 8f03adf.

[icinga-migration]

Updated by mfriedrich on 2016-11-09 14:58:53 +00:00

• Parent Id deleted 11312