You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-11-29 08:17:33 +00:00 (in Redmine)
Icinga Version: v2.5.4-206-gb028ff2
Backport?: Not yet backported
Include in Changelog: 1
Icinga2 version: v2.5.4-206-gb028ff2 (icinga2.x86_64 2.5.4-1.snapshot201611221649.el7.centos @ICINGA-snapshot).
Cluster resyncs everything even if some objects were deleted on one node while other was down.
Good catch. The problem here is that even though the node where the deletion happened does in fact log the deletion - it also gets a "new object" message from the other node when both instances reconnect to each other. This causes the object to be recreated on the instance where the object was initially created.
The proper way to fix this would be to remember deleted objects (kind of, in a tombstone way, really). We'd have to keep creation timestamps for both regular objects and tombstones so we can differentiate between an object that was deleted (object ts less than tombstone ts) - and an object that was re-created after it was previously deleted (tombstone ts smaller than object ts)
This issue has been migrated from Redmine: https://dev.icinga.com/issues/13323
Created by geds on 2016-11-24 16:06:25 +00:00
Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-11-29 08:17:33 +00:00 (in Redmine)
Icinga2 version: v2.5.4-206-gb028ff2 (icinga2.x86_64 2.5.4-1.snapshot201611221649.el7.centos @ICINGA-snapshot).
Cluster resyncs everything even if some objects were deleted on one node while other was down.
To reproduce this issue:
Stop Icinga2 instances on both cluster servers
Edit /etc/icinga2/zones.conf on both 'icinga2a' and 'icinga2b' to enable config replication
Start Icinga2 on both 'icinga2a' and 'icinga2b'
Create a host/service via API
Stop Icinga2 on 'icinga2b'
Delete an object from 'icinga2a' using API:
At this point 'service1' gets synced to Icinga2a from Icinga2b because the object was still present there while it was down
The text was updated successfully, but these errors were encountered: