Configure whether or not to display empty groups

[jelayeb]

Expected Behavior

Empty Hostgroups don't appear in icingaweb2 older versions.

Current Behavior

Empty hostgroups appears with 0 hosts inside.

Your Environment

• Icinga Web 2 version and modules (System - About): 2.5.0
• Operating System and version: Centos7

[dnsmichi]

This was requested by users being changed as it is does not reflect the configured state without them. See #2796 for details.

[jelayeb]

for god i was very happy with that in icingaweb2 empty hostgroups are not showing. i never thought that people will not like it. it was one of the nicest features i had with icingaweb2, and it doesnt make sense to display an empty group inside a monitoring dashboard. but this is seeing differently from admin to another. we can live with this as we did with icinga classic gui. is there a plan to make this configurable to display or not display empty groups??

Thanks

[Al2Klimov]

1. Is it that annoying?
2. Do you have that many empty host/service groups?

[jelayeb]

it is an empty group, why would anyone be interesting seeing an empty group. how will that help admins find status changing from the first look? this is the main task of having an overview look on your infrastructure isn't it?,
i do have only 2 empty groups, they were not empty but the hosts were removed so they became empty. now i have to remove those groups, and add them again whenever i add new hosts with the same functionality that match one of those groups.

[dnsmichi]

Can we please stop this discussion, this leads to nothing. Thanks.

There's always two ways to see this, and your feature request is now to have this configurable. Let's wait what others say.

[Al2Klimov]

now i have to remove those groups (...)

Order is half of life. And IMO it's not a good idea to help sysadmins in not tidying up their Icinga 2 config.

[lippserd]

I think it's good to have this configureable or filterable. Since we try to have as less configuration as possible, I opt for a filter here.

[andral]

We too would like to be able to configure this. We share a global configuration across multiple Icinga2 clusters and some of them now, after the upgrade, show empty host groups.

[flourish86]

I'd suggest to offer this as an option. Here are some drafts. I'd prefer version 2 with the empty ones hidden by default. The state should also be saved.

It's currently not obvious how the host groups are sorted in the list, but we should consider to list empty groups below the non-empty ones.

version 1

version 2

[dnsmichi]

I would opt for version 1. Mainly for the reason that if you have 1000 host groups, you would need to scroll down endlessly to toggle the option. Also, the option focus is on the upper side with filters and more.

[flourish86]

By the way: It's easily possible to filter empty host groups by adding ?hosts_total%3E0 to your url…

At least theoretically. Sadly we discovered a bug, which is addressed in #3940

You can also achieve this using the filter editor, which should pretty much do the job.

See

So, after we fixed this, there should be no need to include an extra control.

[mrdsam]

I'm confused about the added/moved/removed entries here from nilmerg. Is this feature planned to be included? I'd prefer a global default switch so that users don't see / see emtpy host groups by default.

Why is this needed?

We have a distributed monitoring setup with umpteen satellites. Besides a central IcingaWeb, most satellites run an independent local IcingaWeb with their own ido-db, only presenting the hosts/services of the satellite-zone.

Problem: We configure all hostgroups on the root node and they are distributed to all satellites. So, e.g., if a customer only has windows-server, the customer also gets all Network, Firewall, QNAP, FreeBSD, Linux and so on hostgropus he will never ever need. Ending up with 15 empty and 1 'filled' hostgroup.

We and our customers would really appreciate a feature to switch 'show empty hostgroups (AND servicegroups!!)' on or off.

[meni2029]

We have exactly the same context as @mrdsam, therefore we would prefer the version 1 suggested by @flourish86 here

[tbauriedel]

ref/NC/768900