[dev.icinga.com #10000] Removing zones crash remote icinga instances

[icinga-migration]

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

Created by lbetz on 2015-08-26 11:41:24 +00:00

Assignee: (none)
Status: New
Target Version: Backlog
Last Update: 2016-11-14 14:49:20 +00:00 (in Redmine)

Icinga Version: 2.3.9
Backport?: Not yet backported
Include in Changelog: 1

---

Remove a zone on the config (master) server hasn't an effect to remote instances with accept_config. The zone is still there in /var/lib/icinga2/api/zones. Please remove it automatically.

Attachments

• signature.asc lbetz - 2015-08-31 20:21:03 +00:00

---

Relations:

• relates #10000
• relates #10000
• relates #10000
• relates #10000
• relates #10000

[icinga-migration]

Updated by mfriedrich on 2015-08-27 14:27:00 +00:00

• Relates set to 6863

[icinga-migration]

Updated by mfriedrich on 2015-08-31 15:11:19 +00:00

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

Does the zone still exist in your satellite's zones.conf? If so, this isn't a bug.

[icinga-migration]

Updated by lbetz on 2015-08-31 20:21:03 +00:00

• File added signature.asc

No.

[icinga-migration]

Updated by mfriedrich on 2015-09-04 08:55:24 +00:00

• Status changed from Feedback to New
• Assigned to deleted lbetz

[icinga-migration]

Updated by mfriedrich on 2015-09-05 14:52:02 +00:00

• Category changed from API to Cluster
• Status changed from New to Assigned
• Assigned to set to mfriedrich

[icinga-migration]

Updated by tgelf on 2015-12-15 12:59:40 +00:00

It would be great if we could prioritize this, it makes it very easy to break a setup right now. Sometimes it's the users fault, sometimes it isn't, but IMO he shouldn't even need to care at all.

Cheers,
Thomas

[icinga-migration]

Updated by mfriedrich on 2015-12-15 14:31:17 +00:00

• Target Version set to Backlog

[icinga-migration]

Updated by mfriedrich on 2015-12-15 14:33:11 +00:00

• Status changed from Assigned to New
• Assigned to deleted mfriedrich
• Priority changed from Normal to High

[icinga-migration]

Updated by jflach on 2015-12-16 14:44:26 +00:00

I was able to reproduce this:

1. Delete the zone X from /var/lib/icinga2/api/zones/

2. Put something in zones.d/X on the satellite and the master

3. Restart both instances

4. The satellite will complain:

   warning/ApiListener: Ignoring config update for zone 'X' because we have an authoritative version of the zone's config.

5. Delete zones.d/X on the satellite and restart

Success! The satellite will continue to think it has the authority over 'X' and ignore any config updates for this zone.

[icinga-migration]

Updated by mfriedrich on 2015-12-16 18:03:58 +00:00

• Status changed from New to Assigned
• Assigned to set to jflach

@jean

Please poke me on Friday to look into that together.

[icinga-migration]

Updated by mfriedrich on 2015-12-18 15:21:29 +00:00

Apparently that's more easy to reproduce than I thought.

Put a dummy file into /var/lib/icinga2/api/zones/foo/_etc/test.conf and start Icinga 2.

[2015-12-18 14:53:10 +0100] information/ConfigCompiler: Compiling config file: icinga2b/lib/icinga2/api/zones/foo/_etc/test.conf
[2015-12-18 14:53:10 +0100] information/ConfigCompiler: Compiling config file: icinga2b/lib/icinga2/api/zones/master/_etc/example-cmdb/test.conf
[2015-12-18 14:53:10 +0100] information/ConfigItem: Committing config items
[2015-12-18 14:53:10 +0100] information/ApiListener: My API identity: icinga2b
[2015-12-18 14:53:10 +0100] critical/config: Error: Validation failed for object 'foo' of type 'Host'; Attribute 'zone': Object 'foo' of type 'Zone' does not exist.
Location: in icinga2b/lib/icinga2/api/zones/foo/_etc/test.conf: 1:0-1:16
icinga2b/lib/icinga2/api/zones/foo/_etc/test.conf(1): object Host "foo" { }
                                                      ^^^^^^^^^^^^^^^^^
icinga2b/lib/icinga2/api/zones/foo/_etc/test.conf(2):

[2015-12-18 14:53:10 +0100] critical/config: 1 error

The culprit is that we cannot fix that when including the /var/lib/icinga2/api/zones directory, as the config compiler might not yet have the Zone objects available, a dependency problem.

The maybe fix is to not only delete obsolete files from existing zone directories (oldConfig vs newConfig) but also remove unknown zone configuration directories on config sync. Requires more investigation.

[icinga-migration]

Updated by mfriedrich on 2016-03-04 15:54:14 +00:00

• Parent Id set to 11313

[icinga-migration]

Updated by mfriedrich on 2016-06-15 15:37:30 +00:00

https://rt.netways.de/Ticket/Display.html?id=469941

[icinga-migration]

Updated by mfriedrich on 2016-06-21 10:34:45 +00:00

• Relates set to 11994

[icinga-migration]

Updated by mfriedrich on 2016-07-25 14:37:49 +00:00

• Relates set to 12025

[icinga-migration]

Updated by tgelf on 2016-09-12 13:33:43 +00:00

• Relates set to 12707

[icinga-migration]

Updated by mfriedrich on 2016-11-09 14:52:14 +00:00

• Parent Id deleted 11313

[icinga-migration]

Updated by mfriedrich on 2016-11-14 14:49:20 +00:00

• Status changed from Assigned to New
• Assigned to deleted jflach

[icinga-migration]

Updated by mfriedrich on 2016-11-18 14:08:48 +00:00

• Relates set to 11740

[dnsmichi]

I've found the working issue for cluster config sync staging with #4354. I'm closing here in favour of this TODO.