Nagios is dead! Long live Icinga!

[Matthias Flacke]

Steven D. Morrey schrieb:
> So you're saying you've forked Nagios?
> Sounds interesting, but instead of focusing on the personal reasons for a fork (a perceived lack of leadership), can you please explain the technical reasons for the fork.
> I'm quite curious as well as I'm sure are many others, about Icinga, can you please answer the following questions?
>   

First of all - thanks for your attempt to get the discussion back to the
technical level. I think that some of your questions are already
answered on www.icinga.org but I also like to give some details.

> 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.
>   

Generally nothing is wrong with Nagios. At least not from the first
view. Nagios 3 is pretty complete in its functionality, it performs
quite well and has plenty of open and flexible interfaces for many
needs. It is in all its complexity simple to maintain (compared to some
of its competitors) and scales well from small sites to midrange
enterprises. I could continue praising its points, but I will refrain,
because everybody knows ;). Thats why we all use Nagios and why Nagios
has the biggest 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.

> Is there something you feel is architecturally wrong with nagios?
>   

Its a bit early for that question, because we won't change anything in
the architecture now.
If you look at topics like data management, numerous data stores,
limited transports, intransparent distributed setups, lack of consistent
API: yes, there are many points which are improvable. And they will be
addressed, but not in the first step.

> 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.
2. fixing and improving the DB part (called IDO), though it will be
remain fully compatible to ndomod and the existing DB format.
3. GUI - defining a API to control data flow between DB and GUI and add
a flexible and extensible GUI framework.

> 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, a.s.o. We will keep this
compatibility for the first time so far that we even plan to include
patches from Nagios (if Ethan wakes up) and keep Icinga and Nagios
compliant until the general situation has become clearer.

> 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.

> Who is backing this project?  An organization i.e. business of some kind, or something more akin to a users group?
>   

We are both, a team consisting of community members and employees of a
commercial company. We think that neither the community on its own nor a
company without community support can master such a challenge.

> What would be the incentive if any for businesses who have invested heavily in a Nagios based infrastructure to switch?
>   

Although it is a bit early to answer such a question, since the roadmap
is just at its beginning, one point to mention: in terms of investment
protection its vital to put Nagios core development on a broader base.

> Finally, if you use Nagios in a mission critical business application space what is wrong with development occurring as iteration rather than revolution?
>   

We didn't invent the term 'revolution' into this debate ;) Remove the
'r' at the beginning and you get, what we plan: a gentle and cautios
evolution of Nagios.
The most important step at the beginning will be to establish a feeling
in the community that transparency and participation in the development
process is not only a characteristic of plugin and addon programming but
it can also be part of the core evolution. If we manage to get the
communities engagement back, we will have a good chance to ensure all
Nagios' and Icingas future.

-Matthias

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com