[dev.icinga.com #2924] add issue based tests/ directory with various existing issue config

[icinga-migration]

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

Created by mfriedrich on 2012-07-31 23:35:29 +00:00

Assignee: mfriedrich
Status: Resolved (closed on 2012-08-22 19:21:25 +00:00)
Target Version: 1.8
Last Update: 2012-08-22 19:21:25 +00:00 (in Redmine)

---

this is the place where we will keep our issue based configs.

• etc/ with $issue.cfg and some basic stuff
• src/ for all extra binaries or plugins (like the forker)

default make target

make install-testconfig
=> install into /etc/icinga/tests (CFGDIR)

must be included into icinga.cfg, manually.

imho this is a necessary step, as we normally do issue based configs to

1. reproduce the issues
2. use that on further hackery
3. finalize the issue and tests

this should target every config which cannot be automated into perl tests and/or core tests (if test apis are not available e.g.)

Changesets

2012-07-31 23:30:06 +00:00 by mfriedrich 6386f5e

core: add issue based tests/ directory with various existing issue config #2924

refs #2924

2012-08-11 18:10:22 +00:00 by (unknown) 5d8f733

add another bunch of tests and testfixes #2924

refs #2924

2012-08-19 17:09:21 +00:00 by mfriedrich ec9c5e3

core: avoid duplicate events when scheduling forced host|service check (Imri Zvik) #2993

previously, we had introduced a hash-like implementation of
host|service->next_check_event directly pointing to the next
scheduled event. this algorithm is being used within
schedule_host|service_check, determing wether to use the
already assigned event, or scheduling a new event. Since we
did not populate the event_data (host or service object) when
adding a new event to the scheduler, this became insame, always
rescheduling a new event, but not discarding the old one.

This has been partly fixed in #2676 with refactoring that detection
and saving the next_check_event accordingly. But on already scheduled
events which were forced (overridden), another bug was unveiled.

Now that we add the reverse pointer from the host|service event_data
back to the newly created event when forcing a check, we will make sure
that those events are checked correctly, and executed/discarded in the
first place, and not always creating a new event, seperated from the rest.

basically, using the previous implementation (with and without the fix
from #2676) we've created an event bomb under various circumstances,
especially when future events would have been overridden (forced checks).
as events usually result in checks, which can result into perfdata, this
could possibly the root cause for #2924 as well, as other users reported
on the portal as well.

http://www.monitoring-portal.org/wbb/index.php?page=Thread&threadID=26352

With the kind patch provided by Imri Zvik, this now works like expected.
Adapted the debug output a bit myself, so with debug_level=272 it will be
easy to see what happens on events scheduling - and not the non-telling
mess before.

kudos to Imri Zvik for the patch.

refs #2993
refs #2676
refs #2182
refs #2924

2012-08-19 17:29:57 +00:00 by mfriedrich f32fbf8

core: avoid duplicate events when scheduling forced host|service check (Imri Zvik) #2993

previously, we had introduced a hash-like implementation of
host|service->next_check_event directly pointing to the next
scheduled event. this algorithm is being used within
schedule_host|service_check, determing wether to use the
already assigned event, or scheduling a new event. Since we
did not populate the event_data (host or service object) when
adding a new event to the scheduler, this became insame, always
rescheduling a new event, but not discarding the old one.

This has been partly fixed in #2676 with refactoring that detection
and saving the next_check_event accordingly. But on already scheduled
events which were forced (overridden), another bug was unveiled.

Now that we add the reverse pointer from the host|service event_data
back to the newly created event when forcing a check, we will make sure
that those events are checked correctly, and executed/discarded in the
first place, and not always creating a new event, seperated from the rest.

basically, using the previous implementation (with and without the fix
from #2676) we've created an event bomb under various circumstances,
especially when future events would have been overridden (forced checks).
as events usually result in checks, which can result into perfdata, this
could possibly the root cause for #2924 as well, as other users reported
on the portal as well.

http://www.monitoring-portal.org/wbb/index.php?page=Thread&threadID=26352

With the kind patch provided by Imri Zvik, this now works like expected.
Adapted the debug output a bit myself, so with debug_level=272 it will be
easy to see what happens on events scheduling - and not the non-telling
mess before.

kudos to Imri Zvik for the patch.

refs #2993
refs #2676
refs #2182
refs #2924

Conflicts:
	Changelog

[icinga-migration]

Updated by mfriedrich on 2012-07-31 23:35:53 +00:00

• Subject changed from add issue based tests/ directory to add issue based tests/ directory with various existing issue config

[icinga-migration]

Updated by mfriedrich on 2012-08-22 19:21:25 +00:00

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

initial version is done, and works for me. so everyone can now place their own tests, allowing others to testdrive the core based on the past issues.