Skip to content
This repository has been archived by the owner on Nov 6, 2024. It is now read-only.

Need better top down config sync doc/example #327

Open
taylorsmcclure opened this issue Aug 29, 2018 · 2 comments
Open

Need better top down config sync doc/example #327

taylorsmcclure opened this issue Aug 29, 2018 · 2 comments
Assignees
Labels

Comments

@taylorsmcclure
Copy link

taylorsmcclure commented Aug 29, 2018

Hey there! Firstly this cookbook is insanely useful and has saved me much time by not reinventing the wheel, and I am greatly appreciative of that!

I've been scratching my head for a few days trying to get top down config sync working with icinga2_environment. Per the icinga2 docs it recommends placing each endpoint in its own zones.d/{zone} dir. When I use icinga2_environment you can only give it one zone:

icinga2_environment 'chef' do
    environment 'prod'
    enable_cluster_hostgroup false
    enable_application_hostgroup false
    enable_role_hostgroup false
    check_command 'hostalive'
    zone_parent 'master'
    zone 'prod01'
end

Expected Behavior

I would expect a way to tell icinga2_environment to create a new zones.d/{zone} for every matched host in the provided environment similar to the icinga2 docs.

Current Behavior

icinga2_environment creates zones.d/prod01 with host/endpoint/zone objects. It also creates a zone object that encompasses all endpoints for the zone which icinga2 fails to load. Ex:

object Zone "host01.example.com" {
  endpoints = [ "host01.example.com" ]
  parent = "master"
}

object Zone "host02.example.com" {
  endpoints = [ "host02.example.com" ]
  parent = "master"
}

object Zone "host03.example.com" {
  endpoints = [ "host03.example.com" ]
  parent = "master"
}

object Zone "prod01" {
  endpoints = ["host01.example.com", "host02.example.com", "host03.example.com"]
  parent = "master"
}

Results in:

critical/config: Error: Endpoint 'host01.example.com' is in more than one zone.

Possible Solution

It's more than likely I am using icinga2_environment incorrectly or I am not supposed to use this resource for top down config sync. Regardless I found #38 which give me a glimmer of hope that it is somehow possible. However, after staring at provider_instance.rb for an hour I have accepted I am in over my head.

Context

I would like to apply top down config sync using icinga2_environment for my chef environments. We host 100s of individual hosts and top down config sync would be the easiest and less resource intense way to use icinga2.

Your Environment

Chef Version: 13.8.5

@vkhatri vkhatri self-assigned this Aug 29, 2018
@taylorsmcclure
Copy link
Author

Additionally when checking the config with icinga2 daemon -C we get this warning:

warning/Zone: The Zone object 'prod01' has more than two endpoints. Due to a known issue this type of configuration is strongly discouraged and may cause Icinga to use excessive amounts of CPU time.

@taylorsmcclure
Copy link
Author

Looking into this more, I think I understand the issue. icinga2_environment zone option doesn't work too well for top-down config sync. A possible solution would be to introduce another option like zone_self and have it accept a boolean. If true the option would tell the LWRP to create a zone in zones.d/ of the same host name.

I could definitely work on such a feature, but at the moment I am still beta testing things in our environment.

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

No branches or pull requests

2 participants