Icinga / icinga2

The core of our monitoring platform with a powerful configuration language and REST API.
https://icinga.com/docs/icinga2/latest
GNU General Public License v2.0
2k stars 574 forks source link

Don't fail to remove obsolete downtimes #10062

Closed yhabteab closed 4 months ago

yhabteab commented 4 months ago

Before

See #10042

After

––– HTTP/1.1 400 Bad Request Server: Icinga/v2.14.0-175-g81aec894c Content-Type: application/json Content-Length: 246

{ "results": [ { "code": 400, "status": "Cannot remove downtime 'downtime-test!baa2338e-34b0-44a1-94fa-c24f9b1f2b0a'. It is owned by scheduled downtime object 'downtime-test!backup-downtime'" } ] }



fixes #10042
yhabteab commented 4 months ago

Before

[2024-05-16 12:17:00 +0200] debug/ApiListener: Sent update for object 'downtime-test!99532ab9-66fd-4625-881c-1e71acfc3dab': {"config":"object Downtime \"99532ab9-66fd-4625-881c-1e71acfc3dab\" ignore_on_error {\n\tauthor = \"icingaadmin\"\n\tauthoritative_zone = \"master\"\n\tcomment = \"Scheduled downtime by me\"\n\tconfig_owner = \"downtime-test!backup-downtime\"\n\tconfig_owner_hash = \"f15ba79d61f3f10cc45e03469760c8609a808e752b691dcfd798551ba8069091\"\n\tduration = 7200.000000\n\tend_time = 1716220800.000000\n\tentry_time = 1715854620.401736\n\tfixed = true\n\thost_name = \"downtime-test\"\n\tparent = \"\"\n\tscheduled_by = \"downtime-test!backup-downtime\"\n\tstart_time = 1716202800.000000\n\ttriggered_by = \"\"\n\tversion = 1715854620.401923\n\tzone = \"master\"\n}\n","modified_attributes":{},"name":"downtime-test!99532ab9-66fd-4625-881c-1e71acfc3dab","original_attributes":[],"type":"Downtime","version":1715854620.401923,"zone":"master"}
[2024-05-16 12:17:00 +0200] information/ConfigObjectUtility: Created and activated object 'downtime-test!99532ab9-66fd-4625-881c-1e71acfc3dab' of type 'Downtime'.
[2024-05-16 12:17:00 +0200] notice/ApiListener: Relaying 'config::UpdateObject' message
[2024-05-16 12:17:00 +0200] notice/WorkQueue: Stopped WorkQueue threads for 'ConfigObjectUtility::CreateObject'
[2024-05-16 12:17:00 +0200] information/Downtime: Added downtime 'downtime-test!99532ab9-66fd-4625-881c-1e71acfc3dab' between '2024-05-20 13:00:00' and '2024-05-20 18:00:00', author: 'icingaadmin', fixed
[2024-05-16 12:17:00 +0200] critical/ScheduledDowntime: Exception occurred during removal of obsolete downtime for scheduled downtime 'downtime-test!backup-downtime': Error: Cannot remove downtime 'downtime-test!baa2338e-34b0-44a1-94fa-c24f9b1f2b0a'. It is owned by scheduled downtime object 'downtime-test!backup-downtime'

After

[2024-05-16 12:19:53 +0200] debug/ApiListener: Sent delete for object 'downtime-test!99532ab9-66fd-4625-881c-1e71acfc3dab': {"name":"downtime-test!99532ab9-66fd-4625-881c-1e71acfc3dab","type":"Downtime","version":1715854620.401923}
[2024-05-16 12:19:53 +0200] information/ConfigObjectUtility: Deleted object 'downtime-test!99532ab9-66fd-4625-881c-1e71acfc3dab' of type 'Downtime'.
[2024-05-16 12:19:53 +0200] information/Downtime: Removed downtime 'downtime-test!99532ab9-66fd-4625-881c-1e71acfc3dab' from checkable 'downtime-test' (Reason: cancelled by 'downtime-test!backup-downtime' of type 'ScheduledDowntime').
[2024-05-16 12:19:53 +0200] debug/ApiListener: Sent delete for object 'downtime-test!baa2338e-34b0-44a1-94fa-c24f9b1f2b0a': {"name":"downtime-test!baa2338e-34b0-44a1-94fa-c24f9b1f2b0a","type":"Downtime","version":1715785930.19472}
[2024-05-16 12:19:53 +0200] information/ConfigObjectUtility: Deleted object 'downtime-test!baa2338e-34b0-44a1-94fa-c24f9b1f2b0a' of type 'Downtime'.
[2024-05-16 12:19:53 +0200] information/Downtime: Removed downtime 'downtime-test!baa2338e-34b0-44a1-94fa-c24f9b1f2b0a' from checkable 'downtime-test' (Reason: cancelled by 'downtime-test!backup-downtime' of type 'ScheduledDowntime').
yhabteab commented 4 months ago

Sorry! I had to revert a change from feeeded because the origin for the removed child downtimes should be the current endpoint and not some other passed ones.

Al2Klimov commented 4 months ago

And why exactly?

yhabteab commented 4 months ago

And why exactly?

Because the object deletion event for these child downtimes ~is~ will initially be triggered on the current endpoint, and their deletion event should also be synchronised to the sender of the deletion event of the parent downtime.