[dev.icinga.com #12988] Satellite zone setup

[icinga-migration]

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

Created by kelemen on 2016-10-26 12:34:29 +00:00

Assignee: (none)
Status: Closed (closed on 2016-12-13 10:36:26 +00:00)
Target Version: (none)
Last Update: 2016-12-13 10:36:26 +00:00 (in Redmine)

---

Hi,

I have a "master" zone in director that has two servers.

The config looks like this:

cat /var/lib/icinga2/api/zones/master/director/zones.conf

object Zone "master" {
    endpoints = [ "icinga2-master01.something.com", "icinga2-master02.something.com" ]
}

cat /var/lib/icinga2/api/zones/master/director/endpoints.conf

object Endpoint "icinga2-master01.something.com" {
    import "Endpoint Template"

    host = "icinga2-master01.something.com"
    port = "5665"
    log_duration = 1d
}

object Endpoint "icinga2-master02.something.com" {
    import "Endpoint Template"

    port = "5665"
    log_duration = 1d
}

Then I want to create a satellite zone named "nl", I do it with the director module (see nl-zone.jpg).

For some reason, director puts the zone config into the "master" zone file (see nl-zone-preview.jpg)

Then I create an endpoint (see icinga2-client01-endpoint.jpg).

Director puts the endpoint config to the "nl" endpoint file as expected (see icinga2-client01-endpoint-preview.jpg).

Then I go and manually set up the icinga2-client01.something.com server so it is able to communicate with master and receive the configuration files.

cat /etc/icinga2/zones.conf

object Endpoint "icinga2-master01.something.com" {
    host = "icinga2-master01.something.com"
    port = "5665"
}

object Endpoint "icinga2-master02.something.com" {
    host = "icinga2-master02.something.com"
    port = "5665"
}

object Zone "master" {
    endpoints = [ "icinga2-master01.something.com", "icinga2-master02.something.com" ]
}

object Endpoint "icinga2-client01.something.com" {
}

object Zone "nl" {
    endpoints = [ "icinga2-client01.something.com" ]
    parent = "master"
}

object Zone "director-global" {
    global = true
}

I want to keep all the zone/endpoint-related settings in the director, so I comment out the following line in /etc/icinga2/icinga2.conf once the configs have been synced:

# include "zones.conf"

Then I check the configuration in order to check that everything is fine:

[root@icinga2-client01 ~]# icinga2 daemon -C
information/cli: Icinga application loader (version: v2.5.4)
information/cli: Loading configuration file(s).
information/ConfigItem: Committing config item(s).
information/ApiListener: My API identity: icinga2-client01.something.com
critical/config: Error: Validation failed for object 'icinga2-client01.something.com' of type 'Endpoint'; Attribute 'zone': Object 'nl' of type 'Zone' does not exist.
Location: in /var/lib/icinga2/api/zones/nl/director/endpoints.conf: 1:0-1:40
/var/lib/icinga2/api/zones/nl/director/endpoints.conf(1): object Endpoint "icinga2-client01.something.com" {
                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/var/lib/icinga2/api/zones/nl/director/endpoints.conf(2):     import "Endpoint Template"
/var/lib/icinga2/api/zones/nl/director/endpoints.conf(3):

critical/config: 1 error

Appears that there are no data about the "nl" zone in the synced configs.
Additionally, there are no info about "master" and it's endpoints.

How can I fix that?

I really want to keep all the zone/endpoint-related settings in the director.

I want to choose which zones will be synced with servers in "nl" zone. Is that possible? Am I missing something?

Thanks!

Attachments

• nl-zone.jpg kelemen - 2016-10-26 12:09:12 +00:00
• nl-zone-preview.jpg kelemen - 2016-10-26 12:12:23 +00:00
• icinga2-client01-endpoint.jpg kelemen - 2016-10-26 12:13:17 +00:00
• icinga2-client01-endpoint-preview.jpg kelemen - 2016-10-26 12:14:46 +00:00

---

Relations:

• relates #12778
• relates #12183

[icinga-migration]

Updated by mfrosch on 2016-10-26 14:56:33 +00:00

• Relates set to 12778

[icinga-migration]

Updated by mfrosch on 2016-10-26 14:57:56 +00:00

• Relates set to 12183

[icinga-migration]

Updated by mfrosch on 2016-10-26 14:58:01 +00:00

• Status changed from New to Feedback

Yes this is currently a known problem, the Endpoint is actually written to the wrong zone.

But we want to encourage you to define Zone and Endpoint outside of Director. Either way you see it, the cluster configuration can not be created by Director, but built on.

See also #12778

There is also not a clean way to update "external" objects, like commands and pre-existing Zone data without re-kickstarting.

There is #12183 for that

[icinga-migration]

Updated by kelemen on 2016-10-27 06:08:11 +00:00

Thank you for your reply, Markus!

When you say

Either way you see it, the cluster configuration can not be created by Director, but built on.

Could you provide some examples of such configuration?

Thanks!

[icinga-migration]

Updated by mfrosch on 2016-10-27 06:38:48 +00:00

kelemen wrote:

> Either way you see it, the cluster configuration can not be created by Director, but built on.

Could you provide some examples of such configuration?

Well, the problem with rolling out Zone/Endpoint configuration is, that you cannot configure all nodes with a proper config.

They have to be configured, and connected before the Director can deploy config to them. Or else, the config sync would not be working.

What we want to keep:

• Configuring simple Agents (for command_endpoint), where its just one Endpoint in its own zone
  • But: still needs config on the agent in advance

What you could do:

• Configuring satellite zones inside the parent zone (so master would know who to connect to)
  • Satellite still need local zones.conf properly configured

What is not possible:

• Actually configuring the master zone itself
• Configuring clients to tell them who their parent is

What we want to recommend the user, is to take care of that configuration via config mgmt. So the director knows what zones exist, but does not actually manage the object configuration.

[icinga-migration]

Updated by kelemen on 2016-10-27 06:53:49 +00:00

Sorry for probably a dumb question, but, if I understood correctly, you recommend to configure the cluster with all the zones/endpoints and install/kickstart Director later. So all the zones will be imported as external objects that I will not be able to edit with Director.

But what if I need to change something afterwards, how should I sync those changes with Director?

[icinga-migration]

Updated by mfrosch on 2016-10-27 07:08:07 +00:00

kelemen wrote:

Sorry for probably a dumb question, but, if I understood correctly, you recommend to configure the cluster with all the zones/endpoints and install/kickstart Director later. So all the zones will be imported as external objects that I will not be able to edit with Director.

But what if I need to change something afterwards, how should I sync those changes with Director?

Yes, that's something that is missing currently, or better, you would have to re-kickstart (which is possible now without breaking things).

#12183 will offer a better sync for external objects.

We are still discussing how to do it.

[icinga-migration]

Updated by kelemen on 2016-10-27 07:33:24 +00:00

Thank you, Markus!

May you explain the re-kickstart process in more detail please? How should I perform it? I am unable to find any info about it.

[icinga-migration]

Updated by log1c on 2016-10-27 14:53:20 +00:00

if I am not mistaken it should work like this:

create kickstart.ini in /etc/icingaweb2/modules/director/

[config]
endpoint = your-master
;host = 127.0.0.1
;port = 5665
username = your-api-user
password = ***

then run the following command

icingacli director kickstart run

taken from here: https://github.com/Icinga/icingaweb2-module-director/blob/master/doc/03-Automation.md#kickstart-an-empty-director-database

[icinga-migration]

Updated by mfrosch on 2016-10-31 09:58:02 +00:00

There will be a new URL `/icingaweb2/director/kickstart` where you always can update external objects.

[icinga-migration]

Updated by tgelf on 2016-10-31 12:32:47 +00:00

mfrosch wrote:

There will be a new URL `/icingaweb2/director/kickstart` where you always can update external objects.

The url is already available ;) Not official yet, it must still be linked somewhere but it works.

[icinga-migration]

Updated by kelemen on 2016-10-31 12:34:06 +00:00

tgelf wrote:

mfrosch wrote:
> There will be a new URL `/icingaweb2/director/kickstart` where you always can update external objects.

The url is already available ;) Not official yet, it must still be linked somewhere but it works.

Thanks! This looks very useful!

[icinga-migration]

Updated by tgelf on 2016-12-13 10:36:26 +00:00

• Tracker changed from Bug to Support
• Status changed from Feedback to Closed

Closing this as it seems to work, we'll try to get such things easier with the linked issues.