Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.icinga.com #11227] Downtimes and Comments are not synced to child zones #3973

Closed
icinga-migration opened this issue Feb 25, 2016 · 17 comments
Labels
area/distributed Distributed monitoring (master, satellites, clients) blocker Blocks a release or needs immediate attention bug Something isn't working
Milestone

Comments

@icinga-migration
Copy link

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

Created by jeunito on 2016-02-25 02:22:21 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2016-03-29 10:15:06 +00:00)
Target Version: 2.4.5
Last Update: 2016-05-06 14:50:17 +00:00 (in Redmine)

Icinga Version: 2.4.1
Backport?: Already backported
Include in Changelog: 1

Hi I have master1- master2 with 1 satellite configuration.

When I schedule downtime on all hosts and services via the classic ui, the downtime is not propagated to the satellite nodes but only reflected to the other master node.

I have enabled debug logs and I don't see anything that may be related. Same is true for the icinga2.log.

Changesets

2016-03-29 10:09:51 +00:00 by mfriedrich 12dadfd

Fix: Downtimes/Comments not being synced to child zones

fixes #11227

2016-04-20 08:07:24 +00:00 by mfriedrich d0b5898

Fix: Downtimes/Comments not being synced to child zones

fixes #11227

Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-02-25 21:17:39 +00:00

  • Duplicated set to 11234

@icinga-migration
Copy link
Author

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

  • Parent Id set to 11313

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-04 17:18:02 +00:00

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

Please ensure that the satellites have "accept_config = true" set in their api.conf configuration file.

@icinga-migration
Copy link
Author

Updated by jeunito on 2016-03-07 23:37:13 +00:00

Satellites do have the

accept_config = "true" 

configured but the issue still persists.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-16 16:50:48 +00:00

Turn on the debug log on a satellite and check for messages like "Received update for object" containing the downtime object.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-16 16:52:34 +00:00

  • Subject changed from Downtime not propagating so satellites to Downtime not being synced to satellite nodes

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-18 23:54:45 +00:00

  • Duplicated set to 11417

@icinga-migration
Copy link
Author

Updated by MatthiasR on 2016-03-23 12:01:08 +00:00

Hi,
we have the same issue in our primary/satellite installation using Icinga2 with IcingaWeb2.

Our setup:
API.conf: accept_config = true on the satellites.
API.conf: accept_config = false on the primary.

Our findings:
When setting a downtime for an individual service either on the primary or satellite:

  • the downtime appears in the DB table “icinga_scheduleddowntime”
  • the downtime does NOT appear in “icinga2 object list”
  • the downtime is visible on the primary or the satellite
  • the downtime is neither propagated from Satellite to Primary or Primary to Satellite
  • there is nothing about downtimes in the debug.log files. Except: when setting a downtime on the satellite it tries to propagate it to the primary. However our primary runs with “api.conf: accept_config = false” and it refuses to accept the downtime from the satellite.

With recurring downtimes things work as expected and they are being synced between primary and satellite.

This is currently a show stopper for our planned icinga -> icinga2 migration project.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-23 12:14:16 +00:00

  • Status changed from Feedback to New
  • Assigned to deleted jeunito
  • Priority changed from Normal to High

Notes:

  • config objects are not synced bottom-up (see #10733)
  • top down should work with accept_config=true, though runtime created downtimes/comments lack the zone attribute for the host/service they are being created for

TODO:

  • reproduce the issue
  • evaluate setting the zone attribute for comments/downtime objects

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-24 09:17:12 +00:00

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

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-29 10:08:21 +00:00

  • Subject changed from Downtime not being synced to satellite nodes to Downtimes/Comments not being synced to child zones
  • Target Version set to 2.4.5

Setting the zone attribute inherited from the checkable works in my 3 node cluster (2x master, 1x satellite). #10733 will be handled differently.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-29 10:08:42 +00:00

  • Relates set to 10733

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-29 10:11:22 +00:00

I've pushed a fix to git master. Please test the snapshot packages (v2.4.4-282-g016f47d) in your setup. Thanks.

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-03-29 10:15:06 +00:00

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

Applied in changeset 12dadfd.

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-04-20 06:36:20 +00:00

  • Subject changed from Downtimes/Comments not being synced to child zones to Downtimes and Comments are not synced to child zones

@icinga-migration
Copy link
Author

Updated by gbeutner on 2016-04-20 08:15:57 +00:00

  • Backport? changed from Not yet backported to Already backported

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-05-06 14:50:18 +00:00

  • Parent Id deleted 11313

@icinga-migration icinga-migration added blocker Blocks a release or needs immediate attention bug Something isn't working area/distributed Distributed monitoring (master, satellites, clients) labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.4.5 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/distributed Distributed monitoring (master, satellites, clients) blocker Blocks a release or needs immediate attention bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant