Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
icinga-migration opened this issue Nov 27, 2016 · 6 comments

Comments

@icinga-migration
Copy link

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:

@icinga-migration
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

  • Relates set to 13835

@icinga-migration
Copy link
Author

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

  • Status changed from New to Closed

Example added in #13835

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant