So I was going to go on a long diatribe about the necessity for
dependencies across zones, but I found, really by accident, that most of
what I was looking for was already in place. My goal is to have the
master zone send notifications based on dependency enforcement and not
the child zones. So I just have one follow up/question:
The problem is only the master zone knows about dependencies in all the
child zones. When the config gets pushed to Zone A, it doesn't know
about host object Z in Zone B and can't create the dependency. It
creates a critical error and the config fails to lode. Some sample config:
On the config master node.
in /etc/icinga2/zones.d/zoneA/hostX.conf
object Host "hostX" {
address = "XXX.XXX.XXX.XXXX"
vars.nexthop = "hostZ"
}
apply Dependency "child-of" to Host {
parent_host_name = host.vars.nexthop
child_host_name = host.name
assign where host.vars.nexthop
}
in /etc/icinga2/zones.d/zoneB/hosyZ.conf
object Host "hostZ" {
address = "YYY.YYYY.YYYY.YYY"
}
When you run icinga2 daemon -C in the master zone, everything is fine,
because it knows about all the objects across all the zones. But when
you run icinga2 daemon -C in zoneA it complains that it can't create the
Dependency object because the parent object doesn't exist.
Now having said that, I do have a work around. I create a dummy object
in the child zone. Then I use some of that great Icinga config magic.
apply Dependency "child-of" to Host {
parent_host_name = host.vars.nexthop
if( !get_host(host.vars.nexthop ) {
parent_host_name = "dummy_host"
child_host_name = host.name
assign where host.vars.nexthop
}
When this runs in the master zone it compiles fine because
host.var.nexthop is a host object that exists. It also work in the
child zone because it substitutes dummy_host for host.vars.nexthop. It
seems like there should be a better way to do this. I use this dummy
object trick in several places, and it adds a noticeable about of time
to the config compile stage. I'm wondering if changing the object not
existing error from a critical to a warning may solve a lot of this. If
the object doesn't exist just spit out a warning and don't create the
dependency.
_______________________________________________
icinga-users mailing list
icinga-users@lists.icinga.org
https://lists.icinga.org/mailman/listinfo/icinga-users
