> Steven D. Morrey schrieb:
>
>> What was wrong with Nagios from either a user or developer
>> perspective that you felt was not, or could not be addressed
>> through the community.
>>
>
> A second look onto users and developers perspective shows: during
> Nagios 3 development there was a good chance to get fixes and smaller
> changes into the development process. But after the release of
> Nagios3 the big black hole was opened, obvious errors e.g. in the
> scheduling (next check will be in 2010) and timeperiods remain
> unhandled. Until then we encouraged users to examine such errors and
> to provide detailed reports or even patches to the devel list. But
> that was more and more in vain, like Gerhard has described. So far
> concerning our personal motivation (speaking for the community
> members in our team) to bring some progress into nagios development.
>
I agree with this. The issue is not technical but social. It's rather
easily remedied, but it requires Ethan to do some work, or allow
someone else to do work on his behalf.
>> What does Icinga bring to the table or plan to bring to the table,
>> to address these issues?
>>
>
> There are three steps planned until the first release: 1. adding of
> multiple patches from devel list and other sources, from this step
> the core source will be accessible via the usual channels.
I'm not sure exactly which patches you're talking about, but I'm all
agog to see them once the code repositories are released.
> 2. fixing
> and improving the DB part (called IDO), though it will be remain
> fully compatible to ndomod and the existing DB format.
This I don't understand though. Why not take this opportunity to
create a database schema that's easier to manage and understand?
We (op5) determined during a three-week period of testing that
the largest long-term problem with NDOUtils is its database schema,
which prevents it from scaling to huge installations. Since it's
easy to remedy in a way that also makes it simpler to understand
and use, why not take that opportunity now?
> 3. GUI -
> defining a API to control data flow between DB and GUI and add a
> flexible and extensible GUI framework.
>
This, I think, will be rather wasted effort. op5 will release its
new GUI as beta before the nordic meet on nagios (4th of June, iirc).
Availability has always beaten quality in the OSS world, and we're
too close to done right now to decide to stop and wait to see what
icinga might produce in the area sometime in October. Our code is
available for download as a git repository at http://git.op5.org/git
If nothing else, you should at least have a look at it to see what
the competition looks like
>> Is Icinga a true fork, could patches be made available to those on
>> Nagios? Or will Icinga be a distinct product with a new pedigree?
>>
>
> For the first phase which will at least last until the release 1.0 is
> launched in October, we plan to be really conservative with the
> core. It's wrong to say, that we won't touch the core, because we
> plan to add numerous of the outstanding patches from the devel list.
> But we will strictly keep the nagios compatibility for all levels,
> i.e. plugins, transports (NRPE,NSCA), data storage,
Does this also mean object sizes (nebstruct_host_data et al) won't
change? If they do, no eventbroker modules that work with Nagios
will work with icinga, and that would be rather sad, tbh.
>
>> Will migration to Icing be as simple as loading up a new binary,
>> i.e. will it strive to maintain full compatibility with Nagios, or
>> is it trying to break the mold?
>>
>
> I've already stated it before, but say it again clearly: there is no
> break, Icinga will be fully Nagios compatible. Furthermore: we
> expect that you can test it easily within your existing setups to get
> a feeling for it.
>
I'll take this as "The ABI will also remain exactly the same" then,
which should mean noone has to re-compile their eventbroker modules
to make them work with icinga. Right?
>> Who is backing this project? An organization i.e. business of so
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]