[dev.icinga.com #11501] Re-evaluate apply rules after runtime config update via API

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/11501

Created by buhtik on 2016-04-01 10:43:48 +00:00

Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2016-11-16 10:07:14 +00:00 (in Redmine)

Backport?: Not yet backported
Include in Changelog: 1

---

After hosts object were updated, service custom variables were not changed.

Example of service definitions:

apply Service "[CONS][OPS] CPU AVG 5 min." {
import "generic-service"

check_command = "check_zabbix"
vars.ARG1 = host.vars.zabbix_host_id
vars.ARG2 = "zabbix_db"
vars.ARG3 = "system.cpu.load[,avg5]"
vars.ARG4 = host.vars.cpu_load
assign where host.vars.cpu_load
}

Steps to reproduce:

1. Creating host with attributes: {'templates': ['generic-host'], 'attrs': {'vars.location': 'dub', 'vars.connection_time_wait': '14<OK<45', 'vars.cpu_load': '2<OK<4', 'vars.zabbix_agent_health': 'OK=1', 'vars.notes': 'to_add', 'vars.disk_space_opt': '20<OK<80<90', 'vars.role': 'app', 'vars.application': 'SM', 'vars.disk_spase_root': '44<OK<110', 'vars.description': 'Not in prod', 'address': '127.0.0.1', 'vars.zabbix_host_id': '11725', 'vars.type': 'virtual', 'vars.connection_established': '20<OK<40', 'vars.swap_used': '1.2<2<OK<4<4'}}

cat /var/lib/icinga2/api/packages/_api/first-1458367266-1/conf.d/hosts/app-02-prod.dub.conf
object Host "app-02-prod.dub" {
import "generic-host"

address = "127.0.0.1"
vars["application"] = "SM"
vars["connection_established"] = "20<OK<40"
vars["connection_time_wait"] = "14<OK<45"
vars["cpu_load"] = "2<OK<4"
vars["description"] = "Not in prod"
vars["disk_space_opt"] = "20<OK<80<90"
vars["disk_spase_root"] = "44<OK<110"
vars["location"] = "dub"
vars["notes"] = "to_add"
vars["role"] = "app"
vars["swap_used"] = "1.2<2<OK<4<4"
vars["type"] = "virtual"
vars["zabbix_agent_health"] = "OK=1"
vars["zabbix_host_id"] = "11725"
version = 1459503512.559020
}

2. Updating host with attributes: {'templates': ['generic-host'], 'attrs': {'vars.location': 'dub', 'vars.connection_time_wait': '23<OK<44', 'vars.zabbix_agent_health': 'OK=1', 'vars.notes': 'to_update', 'vars.disk_space_opt': '20<OK<80<90', 'vars.role': 'app', 'vars.application': 'SM', 'vars.disk_spase_root': '44<OK<110', 'vars.description': 'Not in prod', 'address': '127.0.0.1', 'vars.zabbix_host_id': '11725', 'vars.type': 'virtual', 'vars.connection_established': '29<OK<99', 'vars.swap_used': '1.2<2<OK<4<4', 'vars.zabbix_name': 'app-02-prod.dub'}}

Please note:
'vars.cpu_load': '2<OK<4' - - WAS REMOVED
'vars.connection_time_wait': '14<OK<45' - WAS CHANGED to 'vars.connection_time_wait': '23<OK<44'
'vars.connection_established': '20<OK<40' - WAS CHANGED to 'vars.connection_established': '29<OK<99'

API Result: {u'results': [{u'status': u'Attributes updated.', u'code': 200.0, u'type': u'Host', u'name': u'app-02-prod.dub'}]}

'vars.connection_time_wait' and 'vars.connection_established' were changed in HOST Custom variables, but were not changed in Service Custom variables.
'vars.cpu_load' was not removed.

File '/var/lib/icinga2/api/packages/_api/first-1458367266-1/conf.d/hosts/app-02-prod.dub.conf' was not changed.

More details in attached screenshots.

Attachments

• create_log.png buhtik - 2016-04-01 10:36:41 +00:00
• created host service cpu.png buhtik - 2016-04-01 10:36:41 +00:00
• created host.png buhtik - 2016-04-01 10:36:42 +00:00
• custom_vars1.png buhtik - 2016-04-01 10:36:42 +00:00
• created host services.png buhtik - 2016-04-01 10:36:42 +00:00
• update host services.png buhtik - 2016-04-01 10:36:42 +00:00
• update host vars.png buhtik - 2016-04-01 10:36:42 +00:00
• updating host log.png buhtik - 2016-04-01 10:36:42 +00:00

---

Relations:

• relates #11501
• relates #11501
• duplicates #11501
• duplicates #11501

[icinga-migration]

Updated by mfriedrich on 2016-04-01 10:59:07 +00:00

Updating custom attributes and rolling back and evaluating apply rules ist not supported by the REST API. That is by design.

[icinga-migration]

Updated by buhtik on 2016-04-01 12:12:15 +00:00

Thanks. Are you going to implement this feature?

[icinga-migration]

Updated by mfriedrich on 2016-04-01 12:22:46 +00:00

It's not planned for now. It involves major changes inside the core and api related stuff making time estimates even harder.

[icinga-migration]

Updated by mfriedrich on 2016-04-04 13:40:35 +00:00

• Tracker changed from Bug to Feature
• Subject changed from API After update host custom variables, service custom variables were not updated. to Re-evaluate apply rules after runtime config update via API
• Priority changed from Normal to Low

[icinga-migration]

Updated by hvhaugwitz on 2016-07-26 17:39:33 +00:00

I second this request.

It would allow one to update the hosts configuration via API on the fly; without the need of time consuming reloads.

Is it possible to schedule this feature for the next release?

[icinga-migration]

Updated by mfriedrich on 2016-07-26 17:46:57 +00:00

Not for 2.5 that's currently in release freeze time (release critical bug fixes only). We'll re-evaluate the importance of remaining issues after the 2.5 release.

[icinga-migration]

Updated by mfriedrich on 2016-08-08 09:15:16 +00:00

• Duplicated set to 11858

[icinga-migration]

Updated by mfriedrich on 2016-08-08 09:19:37 +00:00

• Relates set to 12077

[icinga-migration]

Updated by rhillmann on 2016-09-12 16:09:28 +00:00

+1 Host updates doesnt work either custom attributes or natives. Its going to be changed in memory, but not on disk (/var/lib/icinga2/api/packages/). Pretty useless to update objects if its not changed on disk...

[icinga-migration]

Updated by mfriedrich on 2016-09-12 17:19:05 +00:00

FYI modified attributes are stored in a specific globsl location (/var/lib/icinga2/modified-attributes.conf) and not inside the api package. Those events are replicated throughout cluster nodes. Your comment isn't really helpful either except for your interest in this ticket.

We know that many of you demand this feature, making a change and then automatically re-evaluate everything. It is not easy to implement with transactions, rollbacks, dependency maps, expressions and so forth. Once we have time estimate and release target, we'll update the issue. If one says - I can do it - please share your findings and patches here for futher review/discussions.

[icinga-migration]

Updated by gbeutner on 2016-11-02 06:55:05 +00:00

• Duplicated set to 12991

[icinga-migration]

Updated by mfriedrich on 2016-11-16 10:07:14 +00:00

• Priority changed from Low to Normal
• Target Version set to Backlog

[icinga-migration]

Updated by mfriedrich on 2017-01-09 15:04:22 +00:00

• Relates set to 13757

[rahulshw]

Is there any option, by which, I can forcefully re-evaluate apply rules at regular intervals?

[dnsmichi]

Let a cron do a daemon restart which re-reads the entire configuration.

[rahulshw]

@dnsmichi , restarting the daemon doesn't help in my case. I am using API to update services(checks).
Here is what I did.

1. created an apply rule for dependency
2. created a service via API, such that dependency rule applies
3. checked to see if the dependency is created. yes, it was there
4. updated the service via api, such that the dependency parent changes
5. checked to see if the dependency is updated. no, it was not
6. restarted icinga2 service
7. checked to see if the dependency is updated now. no, it was not updated

[dnsmichi]

Discussion on the community forums: https://community.icinga.com/t/using-api-to-change-host-vars/891

[mickenordin]

@dnsmichi I created #7317 and I am not 100% sure that this is the same problem. The icinga2 api notices that the service is removed and since group membership is stored in the service, not in the servicegroup there is no problem for the api here.

What is needed to fix #7317 would instead be to refresh the servicegroup table when a service or host is deleted, or the hostgroup table only if a host is deleted.

Further more, it works when adding hosts or services through the api, livestatus catches that and adds the service to the servicegroup table, so it seems that there is allready code for updating the table, it just isn't run on delete.