[dev.icinga.com #13283] Missing Groups fiel for services through template

[icinga-migration]

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

Created by birkir on 2016-11-23 01:54:03 +00:00

Assignee: (none)
Status: Assigned
Target Version: (none)
Last Update: 2016-12-07 00:02:41 +00:00 (in Redmine)

---

When creating a service for a host template, it is not possible to set a service-group for that service.

Create new host template -> Add service -> no Groups field.

[icinga-migration]

Updated by tgelf on 2016-12-06 12:57:30 +00:00

• Status changed from New to Feedback
• Assigned to set to birkir

Could you please give me some example of how you name your groups? I'd assume that adding service templates to groups would suffice, so I'm pretty sure you have a use-case I didn't think about :-)

Thanks,
Thomas

[icinga-migration]

Updated by birkir on 2016-12-06 15:03:50 +00:00

In this particular case, i'm using a check_nrpe service, that has a check_command variable.

Different check_commands go into different service_groups, so i would like to be able to put these different checks (that are still originating from the same service template) into different groups, without having to create multiple check_nrpe service templates (check_nrpe_load, check_nrpe_disks, etc.) to assign to host templates.

The alternative way to accomplish this (the way i'm currently handling it) is to have the check_nrpe service template and have multiple Apply rules under it, each apply rule having its own group set to it, the only problem with that is that applied services don't appear under the services tab on hosts where they are applied, which is what i was trying to get from setting the services directly under the host template.

[icinga-migration]

Updated by tgelf on 2016-12-07 00:02:41 +00:00

• Status changed from Feedback to Assigned
• Assigned to deleted birkir

I think I got it. I expected you to have various service (template) definitions, called "Load", "Disks" and so on. As NRPE is special (it's basically a transport, not a command) you're "cheating" by defining the "real" command as a custom var once assigning that service to a host. So, choosing the real command happens in a place where I didn't expect it - and that's why I couldn't imagine the need to assign service groups at that time.

I was temped to ask you to create different Services (templates) for what I see as different Services, you know, "Load", "Disks" - but I still see a use-case for this. NRPE is also different in a way that it's not Director going to configure your available checks on your monitored nodes (like it works with the Icinga Agent). People might define their very own commands on their boxes without you even knowing what they are doing. And they might just want to use the name they used for that specific NRPE command with specific arguments on a single host. NRPE makes this even worse when you follow the (strong) suggestions of not using arguments, you might end up with a lot of different names.

Will sleep once on this one, but I think you got me. The only problem I see is that this would put more pressure on another parallel feature request that deals with extending/overriding/subtracting from a groups array :p

[dgoetz]

I have the same problem with services applied as a service set. The use case is to have the same checks like basic http check (and very specific ones) used in different service sets for different application server. So in this case it makes no sense to define group membership on the service template and apply form already allows to set the groups, so it make sense to have this option also on service sets. If you agree it would be a one line change if I am correct (and a second similar one for the original request).

diff --git a/application/forms/IcingaServiceForm.php b/application/forms/IcingaServiceForm.php
index 6358345..dc06210 100644
--- a/application/forms/IcingaServiceForm.php
+++ b/application/forms/IcingaServiceForm.php
@@ -310,6 +310,7 @@ class IcingaServiceForm extends DirectorObjectForm
 
         $this->addNameElement()
              ->addDisabledElement()
+             ->addGroupsElement()
              ->groupMainProperties();
 
         if ($this->hasPermission('director/admin')) {

Another idea would be to have the groups element on the service set form and let services inherit from it but this would require more work including a new database table. Also it will make configuration easier for some but will perhaps not fit everyone's use case, so I would opt for the first one.

If you agree I can create a pull request for this.

[dgoetz]

The pull request adds the element to add Servicegroups in Service sets and at Host templates.

The logic with inherited and applied groups like it is available for Hostgroups is still missing as it would require a similar resolver and instead of duplicating the code it could be perhaps moved to be more general. But this is to much for my coding skills. ;-)

[Thomas-Gelf]

Well... it has been merged, so let's mention it.