[dev.icinga.com #9100] Multiple sources for zone configuration tree

[icinga-migration]

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

Created by gbeutner on 2015-04-17 13:23:44 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2015-09-17 14:00:59 +00:00)
Target Version: 2.4.0
Last Update: 2015-11-11 14:48:54 +00:00 (in Redmine)

Backport?: No
Include in Changelog: 0

---

• Dynamic configuration API must be aware of zones
• Dynamic configuration changes must be synced to other Icinga 2 instances
  • The instance which has an authoritative copy of the zone's config is responsible for persisting the configuration for dynamically configured objects

Changesets

2015-09-17 11:54:09 +00:00 by mfriedrich 20aa36d

Add zone attribute influencing cluster config sync for API objects

1) No zone defined. The object will only be synced in the local zone for HA purposes.
2) Zone is set to 'master'. Only nodes in the master zone will get this object and updates synced.
3) Zone is set to 'satellite'. Only nodes in the satellite zone, or in parent zones above will get this object and updates synced.
4) Zone is set to 'client'. Only nodes in the client zone, and in parent zones (satellite, master) will get object updates.

Furthermore this commit adds a bit more security measures for syncing object
config bottom-up which is clearly restricted at this time. Clients cannot
send their config to the top, but yet we only support the top-down thing we
also have with the cluster file config sync.

The initial sync will also take the zone relation model into account
and only allow object syncs only when the same conditions apply as written
above.

refs #9927
refs #9100

2015-09-17 12:20:44 +00:00 by mfriedrich 18d645e

Add zone attribute influencing cluster config sync for API objects

1) No zone defined. The object will only be synced in the local zone for HA purposes.
2) Zone is set to 'master'. Only nodes in the master zone will get this object and updates synced.
3) Zone is set to 'satellite'. Only nodes in the satellite zone, or in parent zones above will get this object and updates synced.
4) Zone is set to 'client'. Only nodes in the client zone, and in parent zones (satellite, master) will get object updates.

Furthermore this commit adds a bit more security measures for syncing object
config bottom-up which is clearly restricted at this time. Clients cannot
send their config to the top, but yet we only support the top-down thing we
also have with the cluster file config sync.

The initial sync will also take the zone relation model into account
and only allow object syncs only when the same conditions apply as written
above.

refs #9927
refs #9100

2015-09-17 13:52:54 +00:00 by mfriedrich 7dc3d28

Docs: Add a chapter on cluster config sync for the API

refs #9927
refs #9100

2015-09-18 08:07:13 +00:00 by mfriedrich f2c3bff

Sync cluster config before replaying the logs

If there were objects added at runtime (either through direct api
creation or by using the config file management api) the newly
created objects must be synced first, and then the stored historical
data should be synced.

refs #9927
refs #9100

2015-09-18 10:49:38 +00:00 by mfriedrich 57179f3

Only sync objects actually belonging to a cluster zone

refs #9927
refs #9100

---

Parent Task: #9082

Relations:

• relates #9100
• relates #9101
• relates #9927

[icinga-migration]

Updated by gbeutner on 2015-04-17 13:34:25 +00:00

• Relates set to 9083

[icinga-migration]

Updated by mfriedrich on 2015-05-19 09:00:06 +00:00

• Estimated Hours set to 40

[icinga-migration]

Updated by gbeutner on 2015-08-15 18:08:53 +00:00

Done for the config file management API. Still relevant for #9101 though.

[icinga-migration]

Updated by gbeutner on 2015-08-15 18:09:02 +00:00

• Relates set to 9101

[icinga-migration]

Updated by mfriedrich on 2015-08-18 14:58:36 +00:00

• Relates set to 9927

[icinga-migration]

Updated by mfriedrich on 2015-09-17 11:23:23 +00:00

Specifying the "zone" attribute on object creation/update ensures that a message is sent to nodes

a) in the same zone, modifying the object
b) in the child zone(s) where this object belongs to

Each node will persist the created object and/or modified attributes on its own.

The initial sync between instances also takes the zone model relationship as well as the zone attribute into account.

[icinga-migration]

Updated by mfriedrich on 2015-09-17 11:23:36 +00:00

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

[icinga-migration]

Updated by mfriedrich on 2015-09-17 14:00:59 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 0 to 100

[icinga-migration]

Updated by mfriedrich on 2015-09-21 07:40:36 +00:00

• Backport? changed from TBD to No

[icinga-migration]

Updated by mfriedrich on 2015-11-11 14:48:54 +00:00

• Include in Changelog changed from 1 to 0