Is it not possible to nest one host group inside another?
zones.d/director-global/hostgroups.conf
object HostGroup "2-high-priority-hosts" {
display_name = "2-high-priority-hosts"
assign where host.group == "lof-cluster" || "prod-cluster" in host.groups || "icinga" in host.groups
}
Related items:
Hi,
Hostgroups are somewhat slow for icingaweb. Better use variables and the cube module 
Cheers,
Carsten
Does that still go through Director? We prefer the central management that is still exposed on the API. My question is if nest groups work at all in the first place.
Hi,
As far as I know, nesting is not possible. And group membership is calculated by walking over the apply rules one by one. So it’s completely random whether the host already is part of one group when the rule is checked or not.
So it might work or not and is therefore unusable (and not intended, either)
Thanks and Greeeting Thomas. I think the strategy I will opt for then is to continue to logically categorize services/hosts and adding host.groups or services.groups to my notification apply rules for email/service tickets. I made “exceptions groups,” such as “1-critical-priority-services” to group services that don’t git in a group or are “one-offs”. This should allow me to keep my notification apply rules clean with groups (avoiding direct host/service name and globbing).
As @anon66228339 said: Hostgroups are slow in Icinga Web 2 and they are somewhat of a relic from the dark times of Icinga 1 and the “N-word”. I’d really advise you to use variables on your hosts and services and use them for filters, apply rules and what not. You can do everything that hostgroups do and a lot more.
Cheers,
Thomas
Do I need to use Cube for that, or can we do that with the custom fields date fields as I have done here in host templates, or where is this done?
zones.d/director-global/host_templates.conf
template Host "hadoop-vars" {
vars.nn_mounts = [ "/hadoop" ]
}
I did notice when I deploy something new with Directory that the reload of agents and more takes a minute to process fully.
I added a data field in Director, then added the custom field via my default “Standard Linux Server” host template. I am unsure though how to manually test the variable contents? I applied a value via multi select in Director > Hosts, but I’d like to be able to do “echo $cluster_env” to show the current contents rather than use the Director CLI to show every host.
Edit 1: I see in Overview > Host > Inspect.
@twidhalm, while vars seem nice to apply, they don’t seem to be very good for the overall categorization of host groups / service groups in Icingaweb2. For instance, using cluster_env = “dev cluster” over a host group, removes the bucketing that other help desk staff rely upon and visually accept in Overview > Host groups. While variables can add metadata, there is the cost then on non-admin folk using Icingaweb2.
No, you don’t need Cube to make use of the variables. You can create filters in almost any list of objects within Icinga Web 2 and you can safe those filtered lists as Dashletes for Dashboards or as menu entries. This way you can provide them easily for non-admin users.
vars.nn_mounts = [ "/hadoop" ] is just what I was talking about. You can use it just like the vars.env = "production" you mentioned.
@twidhalm This is working out ok so far, but the part that I miss and do not know how to replicate well, is logic like this for grouping services based on host + service groups:
Any idea on situations like that?
I’m also not sure why my notification apply rule is not taking hold:
## zones.d/master/notification_apply.conf
apply Notification "snow-service-notifications-high" to Service { import "[snow-service-template-high](https://udaicinga.domain.com:8484/icingaweb2/director/notification?name=snow-service-template-high)" assign where service.vars.snow_ticket_priority == "2-high" || "hive-services-lof" in service.vars.service_group || "hive-services-prod" in service.vars.service_group || "certificates" in service.vars.service_group || "icinga-services" in service.vars.service_group || "sysdecom-prod" in service.groups || "2-high-priority-services" in service.vars.service_group }
