Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #3736] Services with empty hostgroups aren't processed even if it has host_name specified (allow_empty_hostgroups=1) #1217
This issue has been migrated from Redmine: https://dev.icinga.com/issues/3736
Created by viranch on 2013-02-27 09:59:59 +00:00
I have allow_empty_hostgroups set to 1. I have a service with hostgroup_name having a hostgroup that has no members. The same service also has values in host_name field. But the service gets ignored (I looked at icinga-core's code, and the service isn't processed in xodtemplate_duplicate_services function).
Attaching a patch to fix it. The patch solves the problem, but I'm not sure if it would give rise to other bugs.
2013-03-10 14:13:24 +00:00 by (unknown) 739287b
Updated by mfriedrich on 2013-03-04 18:18:28 +00:00
allow_empty_hostgroups was introduced for those having partly completed hostgroup templates over the place. so there will be side-effects when actually assigning services to those empty hostgroups, winning over the actual host relation.
likely this is really a bug, but until this isn't properly tested it shouldn't be added upstream.
what's the reason of assigning a service to a hostname and an empty hostgroup? what happens when the hostgroup is not empty - which relation wins, and which one should?
Updated by viranch on 2013-03-04 18:54:34 +00:00
there's no either-or between hostgroups and hostnames for services, its both: hostnames + members of hostgroups
I'm using it on my company's production servers and everything is working fine. the empty hostgroups are silently ignored and service is mapped to specified hostnames. in case of non-empty hostgroups, the services are mapped to the members of the hostgroup along with the hostnames.
with automated icinga configuration deployment, there are many cases when hostgroups become empty. say I have 2 data centers which have their own icinga boxes. now since I have automated configuration deployment (puppet, cfengine, etc) some hostgroups may become empty in one datacenter and others might become empty in the other. these configuration management systems are not aware of what hostgroups are empty and what are not, so there's no workaround in that part of the process.
as I said, there's no winning over among hostgroups and hostnames, when hostgroup is not empty, service should get related to the members of the hostgroup, AND the hostnames specified.
Updated by mfriedrich on 2013-03-08 21:42:07 +00:00
i haven't had the time yet to stumble into some more in-depth code unit testing on 1.x (nearly impossible with that code base), so basically the idea is to create some sample config like these:
and then include them in the dev icinga config, with the empty hostgroups directive enabled, checking the overall functionality - i.e. adding an error message for stdout/logs on config verification must then trigger the output on error. or likewise, comparison old code - new code, with the same configs applied and the new service must not get ignored.
Updated by mfriedrich on 2013-03-10 14:10:11 +00:00
given the idea of the patch, it's valid not to skip a service which also has a valid host relation, in case of an empty hostgroup. so the host_name attribute wins against the empty hostgroup assignment then.