Blacklist a service from service set fails

[weedpump]

Current Behavior

If I blacklist a service from a service set which is directly assigned to the host (not inherited from a host template), the configuration rollout fails:

[2019-05-03 13:33:55 +0000] information/cli: Icinga application loader (version: r2.10.4-1) [2019-05-03 13:33:55 +0000] information/cli: Loading configuration file(s). [2019-05-03 13:33:55 +0000] critical/config: Error: object rule 'ignore where' cannot be used without 'assign where'

Your Environment

• Director version (System - About): master baa3ae2
• Icinga Web 2 version and modules (System - About):2.6.3
• Icinga 2 version (icinga2 --version):r2.10.4-1
• Operating System and version: Ubuntu 18.04.2 LTS

[bewue]

I have the same problem.

• Director version: 1.6.2
• Icinga Web 2 version and modules: 2.6.3
• Icinga 2 version: r2.10.5-1
• Operating System and version: Ubuntu 18.04
• Webserver, PHP versions: apache 2.4.29, php 7.2

[tlo8640]

I ran into the same problem

Director 1.6.3 Icinga Web 2 2.6.3 Icinga2 2.10.5 OS RHEL 7

[petulko8080]

Same problem ocured today for me Director 1.7.2 Icinga2 2.12-rc1 IcingaWeb 2.8.0-rc1

[mkayontour]

I came across this problem today, problem is following: If you assign the set per "static" definition (use add service set on host) and then blacklist one service.

Then this weird configuration is generated.

object Service "Linux MySQL - Connected Threads" {
    host_name = "xxx1472.xxx"
    import "MySQL - Threads-connected"
    groups = [ "mysql_monitoring_all", "mysql_monitoring_opsgenie" ]
    ignore where host.name == "xxx413.xxx"
    import DirectorOverrideTemplate
}

[petulko8080]

more investigation reveal this: if you create host template with service set and then blacklist one service on one (or more) hosts you got in servicesets.conf something like this:

apply Service "AD Health" {
    import "_tpl_generic_nrpe"


    assign where "tpl_host_AD" in host.templates
    ignore where host.name in [ "P_rdc2wke_08", "P_rdc21wke" ]
    vars.nrpe_command = "check_ad"

    import DirectorOverrideTemplate
}

But when you attach service set to more hosts directly, ignore status is always attached into first host found and then generate error

apply Service "AD Health" {
    host.name = "P_rdc1wke"
    import "_tpl_generic_nrpe"

    ignore where host.name in [ "P_rdc2wke_08", "P_rdc21wke" ]
    vars.nrpe_command = "check_ad"

    import DirectorOverrideTemplate
}

apply Service "AD Health" {
    host_name = "P_rdc21wke"
    import "_tpl_generic_nrpe"


    vars.nrpe_command = "check_ad"

    import DirectorOverrideTemplate
}

so workaround - use extra template for every service set which need some blacklist

[sstratford]

I came across this problem today, problem is following: If you assign the set per "static" definition (use add service set on host) and then blacklist one service.

Then this weird configuration is generated.

object Service "Linux MySQL - Connected Threads" {
    host_name = "xxx1472.xxx"
    import "MySQL - Threads-connected"
    groups = [ "mysql_monitoring_all", "mysql_monitoring_opsgenie" ]
    ignore where host.name == "xxx413.xxx"
    import DirectorOverrideTemplate
}

I get exactly the same here...

What i tried:

• use add service set on host
• use assign where on service set

i have to monitor hundreds of switchports and dont want to add them all single !

Versions: Ubuntu: 18.04 icinga2: r2.11.3-1 director: master / d5c94d875745f2f5cb20545e9addd5765383851e icingaweb2 2.7.3 php: 7.3.14-1~deb10u1

zones.d/satellite.icinga.AAAA.local/servicesets.conf

object Service "Port 31 iftraffic" { host_name = "AAAA_SW001" import "Traffic with iftraffic3"

ignore where host.name == "BBB_BBB_SW002"
vars.iftraffic3_interface = "swp30"

import DirectorOverrideTemplate

}

So the hostname assignt is diffrent to the igonored one ??? the BBB_BBB_SW002 is the switch I blacklisted the Service The AAAA_SW001 is the Host I added the Set the first time.

But this should be diffrent Zones and satellites !

[moreamazingnick]

This strange problem still exists in 1.9.1, but here is the catch. 2 machines -> same installation -> same serviceset host gets service set appended manually

machine-1 renders a diabled service from a serviceset with a wrong ignore where, causes deploy to fail machine-2 does not render a disabled service from a serviceset, so the deploy is sucessful

[wp-perc]

Hi guys, this issue is old but still actual. Any news?