[dev.icinga.com #12025] Apply rule in zone affects other zones

[icinga-migration]

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

Created by alexbs on 2016-06-23 08:05:16 +00:00

Assignee: mfriedrich
Status: Assigned
Target Version: Backlog
Last Update: 2016-07-25 14:36:53 +00:00 (in Redmine)

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

---

Hi everyone,

while configuring an Icinga2 distributed setup with multiple zones we found the following bug:

Setup:

• setup with a configuration master for distributing the configuration to other zones.

Expected behavior for apply rules:

• when you setup a service by using an apply rule inside the configuration folder of one child zone
  this rule should only effect objects (Hosts) also defined inside this configurationfolder (zone)
• That is what the documentation says: "Apply rules specified inside zone directories will only affect endpoints in the same zone or below."

Real behavior:

• when i setup a normal apply rule like the following inside the configuration folder of one child zone:
  apply Service "MYping4" {
  import "generic-service"
  check_command = "ping4"
  assign where host.address
  }
  ALL Hosts with an address from all Zones get this service assigned.
  As workaround you can use 'assign where ( host.zone=="satellite")' but this is kind of dirty.

This bug was was allready discussed in the following german forum:
https://monitoring-portal.org/index.php?thread/36515-zonen-werden-bei-services-ignoriert/

kind regards
Alex

---

Relations:

• relates #12025
• relates #10000

[icinga-migration]

Updated by snoopy1978 on 2016-06-28 09:07:56 +00:00

Hi everyone,

I can confirm this issue Alex described. I have exactly the same behaviour.

Greetings
Snoopy

[icinga-migration]

Updated by tgelf on 2016-07-20 18:54:09 +00:00

Just for the records: my personal conclusion in the mentioned thread was that the current behaviour is simply wrong, while what the documentation states mirrors the expected behaviour. Anybody with concerns regarding compatibility should please provide a real-world scenario where the current implementation would be of real use. If such an example is not possible chances are more than good that nobody is able to use it anyway, at least not without one of the mentioned workarounds. And those would not be broken by fixing this.

Cheers,
Thomas

[icinga-migration]

Updated by mfriedrich on 2016-07-25 08:46:36 +00:00

• Relates set to 12217

[icinga-migration]

Updated by mfriedrich on 2016-07-25 14:36:53 +00:00

• Status changed from New to Assigned
• Assigned to set to mfriedrich
• Target Version set to Backlog

We'll discuss a possible implementation and behaviour tests in the next couple of weeks. Unfortunately this won't be added to the 2.5 release due to its freeze time. The referenced documentation issue helps others to understand the possible workaround.

Notes:

• difference between "normal" and "global" zones
• zone objects are not necessarily in memory at the time of evaluate -> requires a compile order dependency
• might affect Fix broken downtime comment sync #10000 as well

[icinga-migration]

Updated by mfriedrich on 2016-07-25 14:37:48 +00:00

• Relates set to 10000

[gunnarbeutner]

There are no plans to support this.