[dev.icinga.com #6836] live evaluation of configuration (CheckCommand) code

[icinga-migration]

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

Created by olaf on 2014-08-01 14:03:28 +00:00

Assignee: (none)
Status: Rejected (closed on 2015-01-12 09:45:10 +00:00)
Target Version: (none)
Last Update: 2015-01-12 09:45:10 +00:00 (in Redmine)

---

background

When working on https://dev.icinga.org/issues/6697 (please see comments on that ticket and code for insight/examples) I ran into trouble. Currently configurationfiles are parsed at the time Icinga is started. So if a command definition is parsed before a service check is parsed settings of variables are not parsed resulting in default true or false states and therefor not complaining about code (icinga -C -c check is passed) but ignoring it.

possible solutions

I think there are three ways to try to facilitate more complex configurationfile defitions.

option #1 : advanced parsing

If the way Icinga parses configurationfiles is changed as follows it will allow for more complex configurationfiles:

• parse the server/service files first so it is know what is needed and what the values of variables are
• parse the command definitions later.
  Obvious drawback to the presumed traversed sequence (compared to the presumed current sequence) is that parsing is much more complex and will require much more (temporary) memory.

option #2a : live evaluation by extending the current grammar

Current grammar and parsing is based on pre evaluating during the parse process, to allow for live evaluation/execution the grammar might need to be adjusted or extended.

option #2b : incorporating forked evaluation based on external scripting

Instead of further development of the current grammar one could also resort to the option of including an external scripting module/language. LUA seems to be a popular choice for that nowadays.

personal view

It is hard to say anything sensible about this without in depth knowledge in the core code of Icinga, but I think that live evaluation of config code might be a far from trivial operation with potential huge impact on code and performance of Icinga.
Option #1 as presented is from a code point of view probably the easiest to implement where as option #2 will provide more options for the future. From an users point of view I think option 2b would be best, but I can think of many reason from a design point of view (performance, busy waiting, complexity) it can be undesirable.

---

Relations:

• relates #8030

[icinga-migration]

Updated by gbeutner on 2014-08-04 08:00:11 +00:00

This is definitely something we want. I'm just not entirely sure about how to do this. One thing we're definitely not doing is adding support for another language (we've actually had support for Python for a while and it's a mess, you'd have to wrap Python snippets in {{{ and }}} or move them to a separate file - both of which isn't ideal for commands)

[icinga-migration]

Updated by mfriedrich on 2014-08-08 13:39:46 +00:00

• Description updated

[icinga-migration]

Updated by mfriedrich on 2014-09-16 09:12:56 +00:00

• Project changed from 37 to Icinga 2
• Category set to Plugins

[icinga-migration]

Updated by mfriedrich on 2015-01-12 09:44:44 +00:00

• Relates set to 8030

[icinga-migration]

Updated by mfriedrich on 2015-01-12 09:45:00 +00:00

Duplicate of #8030

[icinga-migration]

Updated by mfriedrich on 2015-01-12 09:45:10 +00:00

• Status changed from New to Rejected