Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #1572] command to delete host downtime and all associated service downtimes (extinfo.cgi, status.cgi command drop down) #634
This issue has been migrated from Redmine: https://dev.icinga.com/issues/1572
Created by dklueh on 2011-05-20 09:06:05 +00:00
It would be a nice feature to have the option to delete every service-downtime together with the downtime of one or more hosts. At present, at classic ui you have to delete downtimes of hosts and services seperatly.
It should be an option, not automaticaly-
2012-08-07 01:16:40 +00:00 by (unknown) 0372af15171bee5ddd9cb21d50fa2a538e1809c2
2012-08-25 15:09:16 +00:00 by (unknown) 49ea2040503b6c7aeedcbb3db5cabccb8636aa3f
2012-09-23 10:04:39 +00:00 by (unknown) 6dc8bcc
2012-09-23 10:29:00 +00:00 by mfriedrich 4298e14
2012-09-23 11:04:36 +00:00 by mfriedrich 93ef7e5
2012-09-23 11:07:55 +00:00 by mfriedrich 3970736
2012-09-23 13:21:16 +00:00 by ricardo 3991d0d
Updated by ricardo on 2011-05-22 15:02:49 +00:00
Ah yes, the old problem. Which downtimes belong together.
It is possible to find all downtimes for all services an a certain host and delete them. But if this will be iplemented then we have to add a new command or do it in cmd.cgi and send a delete commad for every downtime id.
The thing is, that I don't like the idea of deleting all downtime's for all the services on a host. What if a different department in a company set's a downtime for a single service and this one get's deleted as well.
The actual problem is the downtime implementation itself.
Then you could do that easily. But as I said, this would require a big change and I don't know if we can do this at the moment.
Updated by mfriedrich on 2011-05-23 15:47:05 +00:00
i agree with ricardo here, i normally don't want to delete downtimes for host and the associates services if it comes to that - normally it's just a single service or host being removed - even if not just letting the downtime pass away.
ofc, if you find a way of fiddling through the downtime assigments and add a new command based on the associated host(_id), this could be achieved, but will need the cgi/cmd.c / base/commands.c to encapsulate some more cpu cycles on how to gather all the needed information.
Updated by Anonymous on 2012-09-03 18:58:52 +00:00
Summary of current status of this ticket:
Updated by mfriedrich on 2012-09-23 10:30:21 +00:00
unschedule_downtime will call delete_*_downtime which calls delete_downtime which tries to get a hold on the same shared mutex lock which was previously locked in delete_downtime_by_hostname_service_description_start_time_comment
basically a 2 step down into 2 locks, which explains the core locking up after trying to delete the first downtime.
in order to solve that, we'll unlock the safe before stepping down into unschedule_downtime() once, locking it after returning.
Updated by mfriedrich on 2012-09-23 10:45:52 +00:00
more tests, with command dropdown
Updated by mfriedrich on 2012-09-23 11:06:24 +00:00
beautified the text a bit, telling that this will delete the downtimes of the host, and all services.
Updated by mfriedrich on 2012-09-24 10:34:51 +00:00
sweet. we also got 2 more commands which we are currently not using. but that should be dropped in for seperated issues imho (DEL_DOWNTIME_BY_HOSTGROUP_NAME, DEL_DOWNTIME_BY_START_TIME_COMMENT).
the documentation of DEL_DOWNTIME_BY_HOST_NAME requires an update too, see #3165