[dev.icinga.com #3736] Services with empty hostgroups aren't processed even if it has host_name specified (allow_empty_hostgroups=1)

[icinga-migration]

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

Assignee: mfriedrich
Status: Resolved (closed on 2013-04-06 22:00:57 +00:00)
Target Version: 1.9
Last Update: 2013-04-06 22:00:57 +00:00 (in Redmine)

Icinga Version: 1.8.4
OS Version: CentOS release 6.2 (Final)

---

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.

Attachments

• patch viranch - 2013-02-27 10:00:52 +00:00

Changesets

2013-03-10 14:13:24 +00:00 by (unknown) 739287b

core: fix services with empty hostgroups aren't processed even if it has host_name specified (allow_empty_hostgroups=1) (thx Viranch Metha) #3736

refs #3736

[icinga-migration]

Updated by viranch on 2013-02-27 10:00:52 +00:00

• File added patch

Not sure where did the patch go, attaching again.

EDIT: my bad, the patch was already attached

[icinga-migration]

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?

[icinga-migration]

Updated by viranch on 2013-03-04 18:54:34 +00:00

dnsmichi wrote:

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.

there's no either-or between hostgroups and hostnames for services, its both: hostnames + members of hostgroups

likely this is really a bug, but until this isn't properly tested it shouldn't be added upstream.

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.

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?

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.

[icinga-migration]

Updated by mfriedrich on 2013-03-08 21:24:52 +00:00

• Target Version set to 1.9

hm well, since the config option must be enabled (and is disabled for everyone else), such a change should not harm the other stuff. though, proper testing required.

[icinga-migration]

Updated by viranch on 2013-03-08 21:37:08 +00:00

okay. how do you guys test patches here? may be I can help?

[icinga-migration]

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:

https://git.icinga.org/?p=icinga-core.git;a=tree;f=tests/etc;hb=HEAD

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.

[icinga-migration]

Updated by mfriedrich on 2013-03-10 14:10:11 +00:00

• Subject changed from Services with empty hostgroups aren't processed even if it has host_name specified to Services with empty hostgroups aren't processed even if it has host_name specified (allow_empty_hostgroups=1)
• Category set to Configuration
• Status changed from New to Assigned
• Assigned to set to mfriedrich

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.

[icinga-migration]

Updated by mfriedrich on 2013-03-23 22:41:09 +00:00

• Status changed from Assigned to Feedback

@viranch

you may test current git master or next branch and check for resolval.

[icinga-migration]

Updated by viranch on 2013-03-31 12:14:44 +00:00

thanks dnsmichi, tested with git master and works as expected.

[icinga-migration]

Updated by mfriedrich on 2013-04-06 22:00:57 +00:00

• Status changed from Feedback to Resolved
• Done % changed from 0 to 100

thanks for testing!