Hi there,
it’s been a while since recent release of 1.0.1 in March. Quite a lot of things happened – Hiren Patel and Massimo Forni joined the Core developer team while Hendrik moved on to new projects. But not only refreshening the team makes Icinga Core, CGIs & IDOUtils more valuable this time.
Regarding the GIT commit history and the issue roadmap for 1.0.2 you can imagine the evolution – but this is just an historical listing and does only show basic “who did commit and fix/create what on which date”.
Today Icinga will be “feature frozen” and is up for testing – we need testers for the upcoming Icinga release !!! Guides are available within our development wiki 🙂
What exactly happened since 1.0.1?
Many people were asking what exactly changed in Icinga on the core side – in an easy and readable way. So let’s try it here in 3 Parts 🙂
The changes and enhancements will be split into the Core itsself, the CGIs and the IDOUtils – all of them more or less historically summarized.
Part I starts with …
Icinga IDOUtils
There were some bugs, one major causing data inconsistency but also some enhancements regarding usage and performance.
The current database schema implies a centralized view on the objects table on which all relations are built and joined. During startup of Icinga Core normally old configs get deleted and existing objects marked as inactive. After that, the new config is being checked against those objects and if none found, a new one inserted. This is the expected behavior but a bug leading from the libdbi rewrite caused this check to fail and always inserting a new object. This caused an explosion of the objects table and decreasing overall performance on select/update roundtrips.
Thanks to William Preston the source is fixed, and the remaining data inconsistency with active and inactive objects related to historical checks in the RDBMS also has been fixed. Within the docs you will find a more detailed description and upcoming 1.0.2 will include upgrade SQL scripts in order to keep your database consistency!
Next to that, the string escaping has been modified again not to provoke any more errors. Some RDBMS specific fixes on wrong datatypes were added to.
The source has now completely been rewritten (s/ndo/ido/) and in order to keep everything clean, the core neb api now provides an Icinga specific object version which is used in IDOMOD 1.0.2. The old Nagios ™ one has been kept for compatibility. This implies upgrading both, Core and IDOUtils in 1.0.2.
Another performance issue on MySQL – the binary selects were a nice idea but resulting in major memory and performance problems. Just for getting case-sensitive compare this can be resolved defining the correct collation on the affected columns – thanks again William Preston.
The internal linked hash list for objects has been extended in order to minimize objects selects. This increases overall performance a bit – thanks Opsera Ltd for their Altinity patch.
Some SELECT queries asked for all columns instead of just the primary key if they were just checking for an existing row. Altering this minimizes overall unused RDBMS traffic.
IDO2DB now writes to syslog if it fails to connect to the RDBMS or if the database schema cannot be accessed – and not just quitting without error.
The IDO2DB initscript has been rewritten not to depend only on the lockfile (just like Icinga Core) and if the startup fails this will be shown too, also removing the lockfile.
Jan Drogi (ja5kier on irc.freenode.net #icinga) was asking about persistent configuration during a core restart where IDOUtils clean the config by default – e.g. to keep custom variables relations. Therefore 2 new config options for ido2db.cfg have been added: clean_realtime_tables_on_core_startup and clean_config_tables_on_core_startup. If set to 0 no startup cleaning will be performed.
Stay tuned fo the second part of this series! Meanwhile keep on testing 🙂