[dev.icinga.com #11982] Allow admins to define global Icinga 2 functions

[icinga-migration]

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

Created by tgelf on 2016-06-17 19:02:19 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-06-17 19:02:19 +00:00 (in Redmine)

---

I'd love to make Icinga 2 functions first class citizens in the Director. This would involve a new table storing them, with related information to required parameters and their data type. Would allow for vars.bla = voodoo(), while still completely hiding this complexity from the "end user".

---

Relations:

• relates #11982
• relates #11982

[icinga-migration]

Updated by tgelf on 2016-10-13 12:26:06 +00:00

• Relates set to 12770

[icinga-migration]

Updated by tgelf on 2016-11-29 07:45:33 +00:00

• Relates set to 13353

[Tontonitch]

Could be a solution for me, as explained there https://monitoring-portal.org/index.php?thread/39813-how-to-use-a-host-attribute-value-as-the-default-for-the-corresponding-service-a/

template Service "generic-service" {
  [...]
  if (host.check_period != "") {    check_period = host.check_period  }
  [...]
}

==> replaced by a function
check_period=hostdefined(check_period)

So it would return the value defined for the host, or return the value defined on the service side (provided by a template for example)

template Service "generic-service" {
  [...]
  check_period=hostdefined(check_period)
  [...]
}

[friesoft]

Is this planned for the near future? :)

Our current usecase involves calling functions from the Icinga2 DSL (e.g. Array#join).
See: https://monitoring-portal.org/index.php?thread/40056-check-logfiles-configuration-by-commandline-using-icinga-director/