Some further investigation shows that it does not matter whether the
notification object is created via apply-rule or directly via API.
Delete of service with cascade=1, leaves the notification object intact.
From: Mads Flensted-Urech
Sent: 10. marts 2016 13:06
To: '[email protected]' <[email protected]>
Subject: Icinga2 API: deleting service with cascade does not delete applied
notification
Hi,
We are currently trying out Icinga2, and have come across a challenge when
using the API to create and delete services.
Here is the high-level flow, all done via the API:
1. Create host, with notification enabled (vars.notification.mail set)
2. Create service for the host. A notification object is created, based
on the standard notification apply rule.
3. Delete the service, with cascade=1
4. List the active notifications, and see that the notification created
via apply rule for the service still exists
We first discovered this problem when trying to create the service again, and
the apply rule for the notification fails because the object already exists.
We also tried to delete the notification object directly via the API, but this
is not allowed because the object has not been created via the API.
If we delete the host via the API, with cascade=1, then all objects are deleted
including the notification object for the service.
So to my question: are we doing something wrong? Or is it a bug when deleting a
service?
Below you will find version information and steps to reproduce on vanilla
installation of icinga2.
Regards
Mads
Devops
Danske Bank Markets IT
icinga2 - The Icinga 2 network monitoring daemon (version: v2.4.3)
Copyright (c) 2012-2016 Icinga Development Team (https://www.icinga.org/)
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl2.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Application information:
Installation root: /usr
Sysconf directory: /etc
Run directory: /var/run
Local state directory: /var
Package data directory: /usr/share/icinga2
State path: /var/lib/icinga2/icinga2.state
Modified attributes path: /var/lib/icinga2/modified-attributes.conf
Objects path: /var/cache/icinga2/icinga2.debug
Vars path: /var/cache/icinga2/icinga2.vars
PID path: /var/run/icinga2/icinga2.pid
System information:
Platform: Red Hat Enterprise Linux Server
Platform version: 6.6 (Santiago)
Kernel: Linux
Kernel version: 2.6.32-504.16.2.el6.x86_64
Architecture: x86_64
Steps to reproduce
===============
On vanilla installation of icinga2:
- yum install icinga2
- icinga2 api setup
Below "request" just wraps call to curl with necessary authentication and
headers:
request PUT objects/hosts/node1 { "templates": [ "generic-host" ], "attrs": {
"address": "192.168.11.20", "check_command": "hostalive", "vars.os" : "Linux",
"vars.notification.mail.users": ["icingaadmin"]} }
{
"results": [
{
"status": "Object was created",
"code": 200
}
]
}
request PUT objects/services/node1!customservice1 { "attrs": { "check_command":
"passive", "enable_active_checks": "0" , "max_check_attempts": "1",
"retry_interval": "0"} }
{
"results": [
{
"status": "Object was created",
"code": 200
}
]
}
request DELETE objects/services/node1!customservice1 { "cascade": "1" }
{
"results": [
{
"type": "Service",
"status": "Object was deleted.",
"name": "node1!customservice1",
"code": 200
}
]
}
request GET objects/notifications
"node0!ping4!mail-icingaadmin"
"node0!ping6!mail-icingaadmin"
"node0!ssh!mail-icingaadmin"
"node0!http!mail-icingaadmin"
"node0!disk!mail-icingaadmin"
"node0!disk /!mail-icingaadmin"
"node0!icinga!mail-icingaadmin"
"node0!load!mail-icingaadmin"
"node0!procs!mail-icingaadmin"
"node0!swap!mail-icingaadmin"
"node0!users!mail-icingaadmin"
"node0!mail-icingaadmin"
"node1!ping4!mail-icingaadmin"
"node1!ssh!mail-icingaadmin"
"node1!mail-icingaadmin"
"node1!customservice1!mail-icingaadmin"
_______________
Danske Bank A/S CVR-nr. 61126228 - Kobenhavn
_______________
Denne mail kan indeholde fortrolig information. Har du modtaget mailen ved en
fejl, beder vi dig derfor informere afsender om fejlen - og efterfolgende
slette mailen i dit system uden at videresende eller kopiere den. Selv om
mailen og vedhaeftede bilag efter vores overbevisning er fri for virus og andre
fejl, som kan pavirke computeren eller it-systemet, hvor den modtages og
laeses, abnes den pa modtagerens eget ansvar. Vi patager os ikke noget ansvar
for tab og skade, som er opstaet i forbindelse med at modtage og bruge mailen.
_______________
Please note that this message may contain confidential information. If you have
received this message by mistake, please inform the sender of the mistake, then
delete the message from your system without making, distributing or retaining
any copies of it. Although we believe that the message and any attachments are
free from viruses and other errors that might affect the computer or IT system
where it is received and read, the recipient opens the message at his or her
own risk. We assume no responsibility for any loss or damage arising from the
receipt or use of this message._______________________________________________
icinga-users mailing list
[email protected]
https://lists.icinga.org/mailman/listinfo/icinga-users
