[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