[dev.icinga.com #13325] Make fields from service Object available at host where service is assigned without need to add the fields to host templates

[icinga-migration]

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

Created by shoenscheid on 2016-11-25 09:28:37 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-11-25 10:23:20 +00:00 (in Redmine)

---

Currently a service check and the corresponding fields/vars for a check are assigned the following way:

command -> service template -> apply rule
host template -> host object

if I want to assign a different value just for one host, I have currently 3 solutions:

1. write an apply rule, just matching the host (means the other applies do not match this one)
2. add the service directly to the host object
3. use a general apply, add the fields to the host template and set the different values to this host.

Lets have a look at case 3:

This is the solution, which is close to icinga2 best practice. But the problem is, the fields will be visible at every host, which has the corresponding template assigned. Alternatively I need to stack templates with different fields, which is complex.
I would really like to see the feature to assign fields/vars to specific hosts only. that would stop blowing up hosts with unnecessary fields and implement the best practice

---

Relations:

• duplicates #13068

[icinga-migration]

Updated by tgelf on 2016-11-25 10:23:20 +00:00

Best practice is to add services to host templates. Create templates named "Windows Server", "MySQL Server" and similar on and give them services. They will automagically be rendered as apply rules, this feature is available since Director 1.1.0. Then add those templates to your hosts.

When you go to every hosts services tab you'll see all inherited services and should be allowed to change their fields. That has been introduced with Director 1.2.0 and look like this, mentioned and shown in the release blogpost:

This is pretty cool, as something similar is very hard to get accomplished in Icinga 2. Defaults configured in the applied service would always win over what is configured at a host level. So people writing manual config mostly end up with a weird if/else construct in that scenario. Try it out and have a look at the generated configuration, Director does some magic here.

Please expect this very same feature to also work for all defined apply rules in one of the next Director releases. Then, in case an apply rule matches a host it will show you all applied services and allow you to override the fields for each of them in a similar way.

As evaluating potentially thousands of rules for thousands of hosts at "click speed" wouldn't work out, this will be solved with related cache-like lookup-tables in #13068. A working prototype exists already and is amazingly fast.

In the meantime, working with templates is the way to go. I usually provide not a single service-related field directly at a host (template) level. That would lead to a total mess.

Cheers,
Thomas

[icinga-migration]

Updated by tgelf on 2016-11-25 10:26:53 +00:00

• Duplicates set to 13068

[Thomas-Gelf]

Director v1.3.0 has been tagged and should provide what you have been asking for. No more need for so many templates, you can override single service properties at a host level, even when that service derives from an apply rule.