Problem setting all services in downtime via api

Icinga 2
,
1

we just upgraded to icinga2 v 2.10.5-1 (web is 2.7) and are struggling with issues setting downtimes for all services for a given host via the api.

curl -k -H Accept:application/json -X POST -u user:pw -d @jdata https://our.host.fqdn:443/v1/actions/schedule-downtime
jdata:
{"type":"Host",
"filter":"host.name==\"n1-region-host-app\"",
"author":"\"username\"",
"all_services":true,
"fixed":true,
"start_time":1579900268,
"end_time":1579900568,
"comment":"\"DT-testing-1579900268\""
}

it doesn’t fail because the downtime for the host will be applied but not for any of it’s underlying services.
we’ve tried various iterations and syntax based on the documentation but to no avail.

another weird thing - if we try using type:Service and try to filter for one host and give a “bad” service name, it’ll do all services which is also a potential issue.

any help is appreciated.

2

Hi,

all_services was added with 2.11.

$ git tag --contains f6fc81c6c3
v2.11.0
v2.11.0-rc1
v2.11.1
v2.11.2

Cheers,
Michael

3

in older versions i seem to recall there was a way maybe with a different tag like “child_services” or something? i know it was in the dashboard and our command transport was through the api so i assumed it was possible. but maybe i’m mistaken. thanks, this will make another case for upgrade to 2.11

4

In older versions, you had to fire two API calls - one for the Host and then the Service type. child_services is unrelated to that, this affects dependencies.

1 Like
5

I’m still running 2.10.5 and I have a nightly cron that downtimes all services on certain hosts. Just to clarify Michael’s instructions, you would want to try:

{"type":"Service",
"filter":"host.name==\"n1-region-host-app\"",
"author":"\"username\"",
"fixed":true,
"start_time":1579900268,
"end_time":1579900568,
"comment":"\"DT-testing-1579900268\""
}

and of course, do a "type":"Host"in a second call if the actual host wont be alive either.

Side note, I find something strange about your code block. It references port 443 instead of 5665. Are you reverse proxying?

1 Like
6

not a reverse proxy - goes to a fqdn cname with load balancers. we have a 2 master HA set up so it could be either one as the “active” at any given time.

why not use the “backup” time period method and avoid the cron?

side note - we upgraded to 2.11

7

Hi,

ScheduledDowntime objects depend on Icinga itself, and generate a runtime Downtime object, the next from the current given range. Also, it adds its ownership, so the downtime object cannot be deleted via the web interface.

A cronjob instead is more freely, can schedule multiple downtimes in the future, and those downtimes may be deleted on-demand as well. I prefer the latter, also with some bugs in mind for SD objects (DST if you’re in the EU).

Cheers,
Michael

8

ahhh - that makes sense. in fact just last night i ran into the ownership and not being able to delete from the dashboard gui.