[dev.icinga.com #2878] re-enable state based escalation ranges, using cast tricks

[icinga-migration]

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

Created by mfriedrich on 2012-07-20 16:54:52 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2012-07-31 19:03:56 +00:00)
Target Version: 1.8
Last Update: 2012-07-31 21:23:42 +00:00 (in Redmine)

---

from #306 we need to make sure that livestatus and other neb modules do not fiddle with that, moving it after the typecast cuts, like we already did with address6 and ack expiry end_time.

Changesets

2012-07-20 17:22:36 +00:00 by mfriedrich df420f0

core: re-enable state based escalation ranges, using cast tricks #2878

since we already broke the neb abi a while back, and livestatus
will probably never use any icinga headers itsself, we just
don't give a f*ck about that mad situation - we'll put the
attributes at the end of the structs, tricking the typcasts
leaving the neb api intact.

docs did not receive the configure flag either for a strange
reason, so we can remove that safely from the source as well.

refs #2878

2012-08-25 13:22:26 +00:00 by mfriedrich 54b8eff

fix tests, broken by previous commits

refs #905
refs #2878
refs #2725

2012-11-28 14:37:56 +00:00 by mfriedrich a881643

core: fix wrong escalation notification due to state based escalation range behaviour changes

re-enabling the state based escalation ranges lead into a weird
behavorial change, as the general "is the escalation valid for a
notification" condition was met, but another filter was added (the state
checks and their counters).
Since the default users do not use state based escalation ranges, there
is no other way revoking that behaviour change than making this fully
optional, and reverting to the old known default behaviour by
introducing a new config option, which remains disabled by default.

enable_state_based_escalation_ranges=0

this may not be the best idea within a bugfix release either, but still
it allows those actually wanting to use the state based escalation
ranges to use it without recompiling as we had the request to change
within #2878 already.

reverting to the old known behaviour will probably fix #3441 as well, as
it turns out to be the possible root cause for the faulty condition
checks when an escalation is valid for a notification.

refs #2878
refs #3441

---

Relations:

• relates #2878
• relates #2878

[icinga-migration]

Updated by mfriedrich on 2012-07-20 16:55:48 +00:00

https://dev.icinga.org/projects/icinga-core/repository/revisions/53b0014c4f08e9de22e6eb0f965244b07a6493be

livestatus will probably never support icinga in all its enhanced features, so we can probably add this without any further notice.

[icinga-migration]

Updated by mfriedrich on 2012-07-31 19:03:56 +00:00

• Category set to Escalations
• Status changed from New to Resolved
• Assigned to set to mfriedrich
• Target Version set to 1.8
• Done % changed from 0 to 100

[icinga-migration]

Updated by mfriedrich on 2012-07-31 21:23:42 +00:00

define host {
        use                             linux-server ; use a generic one
        host_name                       localhostescal
        address                         127.0.0.1
        address6                        ::1
        check_command                   check_dummy!0 "here i am"
}


define  service {
        name                            generic-escal-check
        service_description             escalateme
        is_volatile                     0
        check_command                   check_dummy!2 "foobaer"
        max_check_attempts              2
        normal_check_interval           2
        retry_check_interval            1
        active_checks_enabled           1
        passive_checks_enabled          1
        check_period                    24x7
        parallelize_check               1
        obsess_over_service             1
        check_freshness                 0
        event_handler_enabled           1
        flap_detection_enabled          1
        process_perf_data               1
        retain_status_information       1
        retain_nonstatus_information    1
        contact_groups                  abc
        notification_interval           120
        notification_period             24x7
        notification_options            w,u,c,r,f
        notifications_enabled           1
        register                        0
}

define  service {
        use                             generic-escal-check
        host_name                       localhostescal
        contact_groups                  test_contact_group
        service_description             escalate1
}



define serviceescalation {
        host_name                       localhostescal
        service_description             escalate1
        first_critical_notification     3
        last_critical_notification      0
        escalation_options              c,u,r
}