[dev.icinga.com #13333] Support collecting exported zones and endpoints

[icinga-migration]

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

Created by kwisatz on 2016-11-27 00:13:02 +00:00

Assignee: (none)
Status: Closed (closed on 2016-12-30 08:11:55 +00:00)
Target Version: (none)
Last Update: 2016-12-30 08:11:55 +00:00 (in Redmine)

---

I've been trying to export and collect endpoints and zones, rather than having to define them manually either in hiera or my puppet manifests. Which really is impractical with a lot of agents.

E.g. omitting endpoints and zones in the icinga2::feature::api configuration and instead setting them as follows on both the master and agents (with the exception that on the master, one would specify 'master' as the zone name):

    @@icinga2::object::zone { "$::fqdn":
        endpoints => [ "$::fqdn" ],
    }

    @@icinga2::object::endpoint { "$::fqdn":
        host => "$::ipaddress_eth0",
    }

    Icinga2::Object::Endpoint <<| |>>
    Icinga2::Object::Zone <<| |>>

However, the api feature manifest currently defaults to zones and endpoints of "ZoneName" and "NodeName" respectively:

# [*endpoints*]
#   Hash to configure endpoint objects. Defaults to { 'NodeName' => {} }.
#   NodeName is a icnga2 constant.
#
# [*zones*]
#   Hash to configure zone objects. Defaults to { 'ZoneName' => {'endpoints' => ['NodeName']} }.
#   ZoneName and NodeName are icinga2 constants.

This is confusing in an export-collect setup, as it requires one to define at least one endpoint in feature::api and then watch out to collect what is missing, or not define any endpoints or zones, and then exclude the current node when collecting.
Also, the master enpoint and zone must always be exported, but not collected on the master itself, because we need its name and FQDN, not "ZoneName" and "NodeName" in the exported resource. E.g.

    Icinga2::Object::Endpoint <<| title != $::fqdn |>>
    Icinga2::Object::Zone <<| title != $::fqdn |>>

in order to avoid getting duplicate endpoint and zone entries, e.g.

root@icinga:/etc/icinga2# cat zones.conf 
# This file is managed by Puppet. DO NOT EDIT.

object Endpoint NodeName {
}

object Endpoint "icinga.domain.tld"  {
  host = "192.168.1.9"
}

object Zone ZoneName {
  endpoints = [ NodeName, ]
}

object Zone "master"  {
  endpoints = [ "icinga.domain.tld", ]
}

However, when I try to do this, I always end up with the following error, which baffles me since any collected zone is clearly using array syntax for its endpoints:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: "puppet.domain.tld" is not an Array. It looks to be a String at /etc/puppet/environments/cl1_prod/modules/icinga2/manifests/object/zone.pp:55 on node backuppc.int.mde-content.com

I've tried dumping it using notice and it does indeed appear to be a string, not an array:

Nov 27 01:02:28 puppet puppet-master[17263]: (Scope(Icinga2::Object::Zone[ZoneName])) NodeName
Nov 27 01:02:28 puppet puppet-master[17263]: (Scope(Icinga2::Object::Zone[puppet.domain.tld])) puppet.domain.tld

So that leaves me with two questions:

A) Have I missed something regarding that Array/String problem and
B) Could we change the behavior of creating default Endpoints and Zones to make exported resource collection easier?

---

Relations:

• relates #13835

[icinga-migration]

Updated by kwisatz on 2016-11-27 00:29:56 +00:00

Ah, great, looks like I missed one domain.tld instance… o_O

Well the defaults are manageable by simply setting the values to an empty hash.

But the Array/String problem … I've realized, once again, that notice() always outputs as a string, but I'm still a little stuck with that one.

[icinga-migration]

Updated by kwisatz on 2016-11-27 01:26:19 +00:00

Looks like this is actually a Puppet bug, but it's supposedly been fixed in 3.7.0: https://tickets.puppetlabs.com/browse/PUP-1299 with the future parser…
However, that opens up a whole new spectrum of problems with lots of Evaluation Errors and very helpful "This method is deprecated" messages.

[icinga-migration]

Updated by kwisatz on 2016-11-27 12:52:42 +00:00

OK, got this working using the future parser.
Interested in an example for this in the repo/examples ?
I guess some people might have suggestions on how to improve on it.

[icinga-migration]

Updated by bsheqa on 2016-11-28 12:21:47 +00:00

Would be great if you would add examples for this! Maybe create a new examples/example3 directory?

[icinga-migration]

Updated by bsheqa on 2016-12-30 08:11:38 +00:00

• Relates set to 13835

[icinga-migration]

Updated by bsheqa on 2016-12-30 08:11:55 +00:00

• Status changed from New to Closed

Example added in #13835