Provide option to delete downtime for host and its services/children

[dgoetz]

Expected Behavior

It is possible to delete downtime in the same way they are created.

Current Behavior

It is only possible to delete downtime on one object.

Possible Solution

Implement the same logic for deletion like for creation of downtimes (with services/children)

Steps to Reproduce (for bugs)

1. Have a dependency configured in Icinga 2
2. Create a downtime for the object with its children in Icinga Web 2
3. Delete the downtime for the object
4. Children will still have the downtime in effect

Your Environment

• Icinga Web 2 version and modules (System - About): 2.5.0
• Version used (icinga2 --version): 2.8.0
• Operating System and version: RHEL 7

[lippserd]

Hi Dirk,

Thanks for the report. This is a good addition and we should consider it for one of our next releases.

Best regards, Eric

[Al2Klimov]

Suggestion:

On deletion query all child objects and delete all their downtimes.

[dnsmichi]

children is something I'd suggest to split from this feature request. That relies on dependency details you don't have 100% available inside the IDO schema. If you're going the route to use the REST API for that, the remove-downtime action doesn't have any child_options. Dunno if the external commands do provide such.

[Al2Klimov]

@dnsmichi Just tested select * from icinga_scheduleddowntime sdt1 inner join icinga_scheduleddowntime sdt2 on sdt1.scheduleddowntime_id=sdt2.triggered_by_id\G – and it doesn't work. Do you have an idea why?

[dnsmichi]

Those IDs cannot be used for comparisons. scheduleddowntime_id is the PK and only exists inside the database. triggered_by_id is an value populated by Icinga 2. Probably you want to use name for the unique id of a downtime.

[keithf4]

Any progress on this? Just ran into having to manually go and remove 50+ service downtimes for a host I put into an extended downtime but came back up early. Was nice that it only sent out one notification when the downtime started, but it made quite some noise when I had to go remove them all one at a time.

[lippserd]

We did not work on this issue yet. Also, I'm unsure how to solve this best because there is no reliable reference between the created downtimes. But since this is still a reasonable feature request, we will try to sort this out asap. I'll keep you posted.

[keithf4]

Could you use whatever reference that there is that allows you to set all services into downtime when you set a host into downtime? Have it be some sort of similar checkbox when removing a host downtime to remove it from all services as well if the downtime exists.

[sudhagar-raman]

We did not work on this issue yet. Also, I'm unsure how to solve this best because there is no reliable reference between the created downtimes. But since this is still a reasonable feature request, we will try to sort this out asap. I'll keep you posted.

Is there any update yet for deleting all the service downtimes which are linked to a host downtime using API call?

[vineet04]

Any update on this? We have multiple hosts and its services under downtime for extended period. But, downtime are not getting removed manually.

[rstribrn]

Any update on this? Its incredibly annoying having to remove downtime service records manually. I just have to remove 20 hosts with ~400 services. Moreover, there are other hosts/services that I don't want to remove, so I have to cherry-pick from the confused downtime-list page (even without reasonable filtering "by host").

[vineet04]

Any update on this? Its incredibly annoying having to remove downtime service records manually. I just have to remove 20 hosts with ~400 services. Moreover, there are other hosts/services that I don't want to remove, so I have to cherry-pick from the confused downtime-list page (even without reasonable filtering "by host").

At the moment I use Icinga remove-downtime API to get over this issue. You can try this:

$ curl -k -s -u root:icinga -H 'Accept: application/json'
-X POST 'https://localhost:5665/v1/actions/remove-downtime'
-d '{ "type": "Host", "filter": "host.name=="icinga2-satellite2.localdomain"", "pretty": true }' {

This way I was able to remove all the downtime for that hosts. Note, replace username and password with your environment credentials.

[rstribrn]

Thanks a lot. That's exactly what I did after my comment: Enabled Icinga2 API + programmed several internal scripts for handling downtimes, see examples below:

SHARED VARIABLES FOR SNIPPETS BELOW:

# your_host_names_with_asterisk_support
HOST_FILTER="*server123*"

# Icinga2 API Endpoint
ICINGA2_API_ENDPOINT="https://<your icinga2>:5665"

# Icinga2 API Credentials
# Generated by "icinga2 setup api", stored in v /etc/icinga2/conf.d/api-users.conf
ICINGA2_API_CREDENTIALS="root:secret"

COMMENT="downtime comment"
DURATION_STR="1 month"
START_TIME=`date +%s -d "+0 hour"`
END_TIME=`date +%s -d "+${DURATION_STR}"`

REMOVE DOWNLOAD BY HOST:

# https://stackoverflow.com/questions/11966312/how-does-the-leading-dollar-sign-affect-single-quotes-in-bash
curl -k -s -u ${ICINGA2_API_CREDENTIALS} -H 'Accept: application/json' \
 -X POST "${ICINGA2_API_ENDPOINT}/v1/actions/remove-downtime" \
 -d $'{
  "type": "Downtime",
  "filter": "match(filterHost, host.name)",
  "filter_vars": {
    "filterHost": '"\"$HOST_FILTER\""'
  },
  "pretty": true
}'

SCHEDULE DOWNTIME FOR HOSTS:

# https://stackoverflow.com/questions/11966312/how-does-the-leading-dollar-sign-affect-single-quotes-in-bash
curl -k -s -u ${ICINGA2_API_CREDENTIALS} -H 'Accept: application/json' \
 -X POST "${ICINGA2_API_ENDPOINT}/v1/actions/schedule-downtime" \
 -d $'{
  "type": "Host",
  "filter": "match(filterHost, host.name)",
  "filter_vars": {
    "filterHost": '"\"$HOST_FILTER\""'
  },
  "pretty": true,
  "all_services": true,
  "author": "admin",
  "comment": '"\"$COMMENT\""',
  "fixed": true,
  "start_time": '${START_TIME}',
  "end_time": '${END_TIME}'
}'

RESCHEDULE CHECK host+services (useful after manually removing downtimes):

# https://stackoverflow.com/questions/11966312/how-does-the-leading-dollar-sign-affect-single-quotes-in-bash
curl -k -s -u ${ICINGA2_API_CREDENTIALS} -H 'Accept: application/json' \
 -X POST "${ICINGA2_API_ENDPOINT}/v1/actions/reschedule-check" \
 -d $'{
  "type": "Host",
  "filter": "match(filterHost, host.name)",
  "filter_vars": {
    "filterHost": '"\"$HOST_FILTER\""'
  },
  "pretty": true,
  "force": true
}'

# https://stackoverflow.com/questions/11966312/how-does-the-leading-dollar-sign-affect-single-quotes-in-bash
curl -k -s -u ${ICINGA2_API_CREDENTIALS} -H 'Accept: application/json' \
 -X POST "${ICINGA2_API_ENDPOINT}/v1/actions/reschedule-check" \
 -d $'{
  "type": "Service",
  "filter": "match(filterHost, host.name)",
  "filter_vars": {
    "filterHost": '"\"$HOST_FILTER\""'
  },
  "pretty": true,
  "force": true
}'

[nilmerg]

With the upcoming Icinga Web 2 Version 2.9.3 and Icinga v2.13, all service downtimes created by ticking the All Services option (when scheduling a host downtime) will get cleared automatically by Icinga 2 if the host downtime is removed.

Note that this only applies to host downtimes created with Icinga Web 2 Version 2.9.3. Previous versions of Icinga Web 2 schedule these service downtimes differently and so the automatic removal won't work for them.

Also note, that this generally only applies to child downtimes for a host's services. Downtimes for child hosts will not be removed automatically yet.

[K0nne]

@nilmerg
Does that mean there will be an option for the IcingaWeb2 API to remove downtimes in the same way as creating them? (https://%icingamaster%/icingaweb2/monitoring/host/schedule-downtime?host=%hostname%)

[nilmerg]

Everything I wrote was about the current state. No word about the future and none about an API. So: No.

[K0nne]

Thanks for clarification