[dev.icinga.com #13413] Wrong order of import when directly assigned service

[icinga-migration]

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

Created by TheFlyingCorpse on 2016-12-06 08:45:21 +00:00

Assignee: TheFlyingCorpse
Status: Feedback
Target Version: (none)
Last Update: 2016-12-06 10:05:35 +00:00 (in Redmine)

---

Use case:
Have host objects as aliases of a host and tell it where it needs to go test stuff when it needs to use the icinga2 agent when applicable.

It correctly adds the service to "murggh" in the apply rule, however it fails to directly assign it when you go down to service.conf for the master zone.

This minified configuration showcases the issue, its cleaned up and tried outside of director to see the issue:

#/etc/icinga2/zones.d/director-global/templates.conf
template Host "Icinga2Host" {
    check_command = "cluster"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 1m
}

template Host "PingDevice" {
    check_command = "hostalive"
}

template Service "_Icinga2ParentCheck" {

  if (host.vars.cmd_endpoint != "") {
      command_endpoint = host.vars.cmd_endpoint
  }
}
template Service "_Icinga2Local" {
    check_command = "dummy"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 1m
    command_endpoint = host_name
}

template Service "_Icinga2Remote" {
    check_command = "dummy"
    max_check_attempts = "3"
    check_interval = 1m
    retry_interval = 1m
}
template Service "Icinga2ParentCheck - icinga" {
    import "_Icinga2Local"
    import "_Icinga2ParentCheck"

    check_command = "icinga"
}
apply Service "Icinga2ParentCheck - icinga check" {
    import "Icinga2ParentCheck - icinga"

    assign where host.name == "murggh"

}

#/etc/icinga2/zones.d/master/endpoints.conf
object Endpoint "deb-mysql-host.labdomain.net" {
    host = "deb-mysql-host.labdomain.net"
}

#/etc/icinga2/zones.d/master/zones.conf
object Zone "deb-mysql-host.labdomain.net" {
    endpoints = [ "deb-mysql-host.labdomain.net" ]
    parent = "master"
}

#/etc/icinga2/zones.d/master/hosts.conf
object Host "i2master01.labdomain.net" {
    import "Icinga2Host"

    address = "i2master01.labdomain.net"
    vars.OSFamily = "Debian"
}

object Host "gateway-10.13.37.0" {
    import "PingDevice"

    address = "10.13.37.1"
}

object Host "swoopdidoo" {
    import "PingDevice"

    address = "127.0.0.1"
    vars.cmd_endpoint = "deb-mysql-host.labdomain.net"
}

object Host "murggh" {
    import "PingDevice"

    address = "127.0.0.1"
    vars.cmd_endpoint = "deb-mysql-host.labdomain.net"
}
object Host "deb-mysql-host.labdomain.net" {
    import "Icinga2Host"

    address = "deb-mysql-host.labdomain.net"
    vars.OSFamily = "Debian"
}

#/etc/icinga2/zones.d/master/services.conf
object Service "Icinga2ParentCheck - icinga" {
    host_name = "swoopdidoo"
    import "Icinga2ParentCheck - icinga"

}

Issue:

root@i2master01:/etc/icinga2/zones.d/master# icinga2 daemon -C
information/cli: Icinga application loader (version: v2.5.4-214-ge954a0e)
information/cli: Loading configuration file(s).
information/ConfigItem: Committing config item(s).
information/ApiListener: My API identity: i2master01.labdomain.net
critical/config: Error: Validation failed for object 'swoopdidoo!Icinga2ParentCheck - icinga' of type 'Service'; Attribute 'command_endpoint': Object 'swoopdidoo' of type 'Endpoint' does not exist.
Location: in /etc/icinga2/zones.d/director-global/templates.conf: 23:5-23:32
/etc/icinga2/zones.d/director-global/templates.conf(21):     check_interval = 1m
/etc/icinga2/zones.d/director-global/templates.conf(22):     retry_interval = 1m
/etc/icinga2/zones.d/director-global/templates.conf(23):     command_endpoint = host_name
                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/etc/icinga2/zones.d/director-global/templates.conf(24): }
/etc/icinga2/zones.d/director-global/templates.conf(25):

critical/config: 1 error

Moving "import" above the host_name resolves the config validation error in the masters services.conf.
Do you think this is possible to correct in Director?

[icinga-migration]

Updated by tgelf on 2016-12-06 09:20:39 +00:00

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

Nice problem :D

• could you please give me some details on how/why those config files finish in /etc?
• to me this looks like you're putting manual config in director-global, but I'm slightly confused as there are also files that seem Director-generated in /etc
• I would advise against doing so. In future the Director should also learn to move the config-master role on it's own, so in case one master dies it would deploy to the other one and remove it's config package from that one once it comes back. This would not be possible when Zones managed by Director exist in your /etc/icinga2/zones.d. So regardless of the original issue, please let me understand what you are trying to build here, hopefully allowing me to figure out what I could do better to not force you to do whatever you have been trying to do here ;)

And, last but not least: why don't you let the Director care about those endpoints and use the "Run on agent / use agent" flag on your services?

I cannot switch that order in a generic way as we depend on this with our apply rules. But I guess ™ I could do so for single objects. There was a core issue involved with at least one of them, so YES I guess this could be done. But it requires some care and research first. In the meantime I'd love to hear more about your thoughts on all this ;-)

Cheers,
Thomas

[icinga-migration]

Updated by TheFlyingCorpse on 2016-12-06 09:29:37 +00:00

• They end in /etc because I tried to recreate it and see how the config was being interpreted by Icinga2, seeing no obvious errors for hours!
• I am putting the config of the "_Icinga2ParentCheck" in as file via fileshipper (with a manually added same name template to the database that is disabled, so it can be used via Director)
• The zones.d was just to test the generated config and more easily move around stuff.

The key reason here why I dont use the "icinga agent" directly on the alias (it is used on all managed OS hosts) is because it itself is just a dns cname of the host, its a "bare" host object containing the checks just relevant to the alias. This is useful if you have say 10 different functions for a host and they dont share a customer. its bad to show one massive object for everything that is on it, when its just 1 customer affected by a stopped (windows/linux) service.
Example:

• Host - Server:
  • Monitor vitals for OS
• Host: ServiceAlias 1:
  • Monitor vitals just for ServiceAlias 1, such as running service
  • Check MySQL, etc.
• Host: ServiceAlias 2:
  • Monitor vitals just for ServiceAlias 2, such as running service
  • Check http, etc.

btw: I think I have found a workaround:
in "library/Director/Objects/IcingaObject.php", in "public function toConfigString()", move "$this~~renderPrioritizedProperties()," down 1 line below "$this~~>renderImports(),"

Thoughts?

[icinga-migration]

Updated by tgelf on 2016-12-06 09:37:06 +00:00

TheFlyingCorpse wrote:

btw: I think I have found a workaround:
in "library/Director/Objects/IcingaObject.php", in "public function toConfigString()", move "$this~~renderPrioritizedProperties()," down 1 line below "$this~~>renderImports(),"

Thoughts?

It would fix your issue but probably introduce other ones. There was a reason for a761bb1, but unfortunately I do not remember the details right now.

[icinga-migration]

Updated by TheFlyingCorpse on 2016-12-06 09:40:29 +00:00

Thanks! I'll try it out a bit. So far I do not have dictionaries used with apply rules, just assign rules :-)

I'll try to look into the apply rules at a later date and see if I can piece this out.

[icinga-migration]

Updated by tgelf on 2016-12-06 09:42:04 +00:00

TheFlyingCorpse wrote:

The key reason here why I dont use the "icinga agent" directly on the alias (it is used on all managed OS hosts) is because it itself is just a dns cname of the host, its a "bare" host object containing the checks just relevant to the alias.

Ah, remember that we talked about something similar. Now the picture is getting clearer :-) So you have multiple host objects with different names for the very same host, sitting in it's parent zone, correct? What if we introduce this as a feature? Need to find a good name for it, like "Related endpoint node" or so. That way you could benefit from all the magic already existing for Agents.

What do you think about it?

[icinga-migration]

Updated by TheFlyingCorpse on 2016-12-06 09:44:10 +00:00

My thoughts: Yay!

[icinga-migration]

Updated by tgelf on 2016-12-06 09:53:01 +00:00

TheFlyingCorpse wrote:

My thoughts: Yay!

Cool :-) Now comes the toughest part: naming. How should we call it?

[icinga-migration]

Updated by TheFlyingCorpse on 2016-12-06 10:05:35 +00:00

Good question. I called it "parent icinga node" internally, but I am not sure that is fitting.

[TheFlyingCorpse]

Subscribed to this.