[dev.icinga.com #9170] Notification Apply cannot access nested service dictionaries

[icinga-migration]

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

Created by mfriedrich on 2015-04-24 16:12:52 +00:00

Assignee: (none)
Status: Rejected (closed on 2015-04-27 06:02:16 +00:00)
Target Version: (none)
Last Update: 2015-04-27 09:29:29 +00:00 (in Redmine)

Icinga Version: 2.3.4
Backport?: Not yet backported
Include in Changelog: 1

---

Problem

Notification Apply cannot access nested service dictionaries populated in service apply rules.

critical/config: Error: Invalid field access (for value of type 'String'): 'bar'
Location:
/etc/icinga2/tests/fit.conf(27): 
/etc/icinga2/tests/fit.conf(28):   users = [ "bumsti" ]
/etc/icinga2/tests/fit.conf(29):   assign where service.vars.foo.bar == "bumsti"
                                                ^^^^^^^^^^^^^^^^^^^^
/etc/icinga2/tests/fit.conf(30): }
/etc/icinga2/tests/fit.conf(31): 

critical/config: 1 error

Configuration

object Host "fit1" {
  import "generic-host"
  vars.foo.bar = "bar"
}
object Host "fit2" {
  import "generic-host"
  vars.foo.bar = "bar"
}


object Service "test" {
  check_command = "dummy"
  host_name = "fit1"
  vars.foo.bar = "blub"
}

apply Service "test" {
  check_command = "dummy"
  vars.foo = host.vars.foo
  vars.foo.bar = "bumsti"
  assign where host.vars.foo
  ignore where get_service(host.name, "test")
}

apply Notification "notify-bumsti" to Service {
  import "mail-service-notification"

  users = [ "bumsti" ]
  assign where service.vars.foo.bar == "bumsti"
}

object User "bumsti" { }

Tested w/ 2.3.3, support/2.3 & master.

---

Relations:

• relates #9170

[icinga-migration]

Updated by gbeutner on 2015-04-27 06:02:16 +00:00

• Status changed from New to Rejected

That's because vars.foo is a String and the String class does not have an attribute called 'bar'.

[icinga-migration]

Updated by mfriedrich on 2015-04-27 08:43:10 +00:00

• Relates set to 9182

[icinga-migration]

Updated by mfriedrich on 2015-04-27 09:29:29 +00:00

Ok, I do have multiple configuration snippets using 'vars.foo' and one of them is already a string. Which makes the error message valid but misleading - separate issue for improved error message in #9182.

nbmif /etc/icinga2 # grep -r foo tests/
tests/7576.conf.dis:    "monday" = "foobar 00:00-24:00" 
tests/trivago.conf:  email = "foo@bar.com"
tests/trivago.conf:  email = "foo@bar.com"
tests/7311.conf.dis:  vars.macro2 = [ "$host.vars.blub", "host.vars.foo$" ]
tests/7311.conf.dis:    //"--server" = "$address $foobar$foo"
tests/5926.conf:  command = "echo \"address: $address$ address_service: $service.vars.address$ foo: $foo$ keks: $keks$ god: $god$\""
tests/5926.conf:  vars.foo = "bar"
tests/5927.conf:apply Service "5927-foo" {
tests/5927.conf:  assign where service.name == "5927-foo"
tests/fit.conf:  vars.foo.bar = "bar"
tests/fit.conf:  vars.foo.bar = "bar"
tests/fit.conf:  vars.foo.bar = "blub"
tests/fit.conf:  vars.foo = host.vars.foo
tests/fit.conf:  vars.foo.bar = "bumsti"
tests/fit.conf:  assign where host.vars.foo
tests/fit.conf:  assign where service.vars.foo.bar == "bumsti"
tests/6105.conf:  vars.foo = "bar"
tests/6105.conf:apply Service "6105-foo" {
tests/6105.conf:  assign where service.name == "6105-foo"
tests/6105.conf:  vars.bar = "foo"
tests/6479.conf:apply Service "6479-foo" {
tests/6479.conf:  assign where service.name == "6479-foo"
tests/5912.conf.dis:  host_name = "foo"