[icinga-devel] Icinga Core API

Michael Friedrich michael.friedrich at univie.ac.at
Fri Sep 9 13:01:50 CEST 2011


we've been talking about that during my nuremberg session, and clarified 
various open questions and some criticism.

On 2011-06-30 09:59, Gunnar Beutner wrote:
> Something as complex as our MQ idea should definitely be able to stand
> up to a certain amount of scrutiny. I'd rather spend more time on
> discussing issues with our design (we're not infallible after all :))
> than to start coding only to realize later on that we've missed some
> major problems.

the proposed dersign picture in the wiki now reflects the latest 
thoughts, and will be enhanced by various ideas we've discussed in the 
past days. but for a final proof of concept, the shared public design 
should be ready.
therefore, there will be a public git repository next to dev tracker 
project being registered within the next days.

> It would definitely make sense to break down the MQ design into
> individual milestones which can be reviewed independently - we're
> certainly not going to throw a big blob of code at you once everything
> is "finished".

one of those will be to target the core zeromq parts in the first place, 
and focus on the libimq and libicinga parts for check distribution at 
first glance. any other milestones will be reflected on the public 
roadmaps and the wiki pages to be coming.

> It doesn't necessarily have to be ZeroMQ. The description on the wiki is
> actually pretty much implementation-agnostic. ZeroMQ is merely what we
> came up with during the weekend and it seems to have a number of
> properties other MQ implementations do not have. For one it doesn't have
> any external dependencies (like Java or Oracle DB) and can be embedded
> directly into applications - without having to run a separate message
> broker.
> Obviously RabbitMQ and other MQs have their own advantages too. I'll try
> and come up with a more detailed comparison matrix for the MQ
> implementations we've been investigating so far.

from what i've seen, either in this context, or a as buffer replacement 
for idoutils, it will be a valuable attempt. although, as discussed, it 
should be kept completely optional to the other parts and users should 
get the normal working core without any further linkage, unless the new 
module is loaded.
furthermore, the new module definition introduced in icinga 1.4.x will 
allow us not to depend on icinga.cfg changes like broker_module but to 
create our very own definition for further testing and also for module 

> While the first proof-of-concept version of the API/MQ implementation
> will most likely not feature the whole spectrum of API commands we
> shouldn't just focus on read-only GET queries as in doing so we might
> easily miss issues we'll encounter later on (like the whole
> thread-safety issue when updating/creating Icinga objects via the MQ).

discussed and tbd.

> Ideally these components wouldn't be accessing the Core API directly but
> would instead use libicinga. One benefit of that would be that idoutils
> could asynchronously pull event notifications from the message queue and
> process these events without blocking the Icinga Core. In that scenario
> the message queue would also take care of buffering events - which I
> guess is what you meant by "cached worker".

discussed, clarified and straight up, libicinga will be the "api" to be 
used for external applications.

> Being able to dynamically reconfigure Icinga would be a very cool
> feature. However the changes required for this lie somewhat outside the
> scope of the API. In order to implement this the Icinga Core would first
> have to provide basic support for this sort of reconfiguration
> (persisting dynamically added objects, ability to remove objects, etc.).

true that, this isn't possibly currently, and needs proper core 
implementation in the first place.

> One thing I'm concerned about here is backwards-compatibility with other
> plugins like mk_livestatus (which probably wouldn't be able to
> gracefully handle deleted objects - not without modifications anyway).

if there's compatibility breakage with deep down core functionality 
using modules like mklivestatus tries to do, we might break things with 
icinga2 which would provide us and addon devs to implement a common 
strategy on resolving such things in order to stay compatible on a new 
major release tree.

> While it should be made obvious to our users that the Core API/MQ
> feature-set is highly experimental in the first couple of versions (and
> therefore should be disabled by default) having these components as an
> external set of patches or a NEB module would impede our efforts to
> actually get people to test these changes - which is pretty much the
> only way of finding bugs and other problems.

either it will be a configure option, or, if it's a module being loaded, 
an addon via make install target plus config option (plus module 
definition). this will allow us to release icinga as well known and 
loved, but also introduce changes to valuable testers out there.

having talked in person about that makes the path to go more clear, and 
i'm hoping that i'll get some time to hack around myself with zeromq.

kind regards,

DI (FH) Michael Friedrich

Vienna University Computer Center
Universitaetsstrasse 7 A-1010 Vienna, Austria

email:     michael.friedrich at univie.ac.at
phone:     +43 1 4277 14359
mobile:    +43 664 60277 14359
fax:	   +43 1 4277 14338
web:       http://www.univie.ac.at/zid

Icinga Core&  IDOUtils Developer

More information about the icinga-devel mailing list