Nagios is dead! Long live Icinga!

[Andreas Ericsson]

Hendrik Baecker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Andreas Ericsson schrieb:
>>> Matthias Flacke wrote:
>>> 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 ;-)
>>
> Sorry that I didn't review your code before asking this question. I
> assumed this already in my other post:
> Do I need merlin, as a redundant/scalable daemon between native nagios
> and a database?

Yes. To prevent lockups in Nagios in case of a DB hang, the merlin module
is extremely simple and only knows how to transport an event from Nagios
through a unix domain socket to a daemon that takes care of the event
(which is exactly how NDOUtils does it).

> If so: What if you get users with smaller environments which won't
> profit of the pure merlin power?
> 

Then you don't configure any secondary nodes for merlin, and you waste
one cmp+branch for each event it receives. In the grand scheme of things,
it's comparable to running printf("hello world!\n") once every 40 minutes
to increase the load on your Nagios server.

>>>> 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.
>>>
>> One out of two is not too shabby. The community could do it without the
>> company, but the company couldn't do it without the community. I know
>> that at least some of Ethan's grief against Netways is not unfounded
>> (and so does Hendrik Baecker I believe; IIRC he was standing next to
>> me and Ethan during last years Nagios Conference in Nuremberg when the
>> original source of grief was discussed. Ah well).
>>
> I agree with you but both parties have one shared intent: further
> development.
> 

Even so, making Bernd Erk the project manager was, politically, a very
bad move. Ah well.

> We talked within the community part before about the pro's and con's
> about this step. Many of us were just a small step away from dropping
> all that nagios stuff. It would be easier for us to tell our boses that
> nagios development might be stale, using the actual release until we got
> another commercial alternative - but we wouldn't have one.
> To the grief discussion: I know I have a horrible memory for details,
> but I'm sure that I would remember such a discussion if I stand next to it.
> But does it matter? What am I interested in trouble between two business
> parties as a community member, wanting to see more improvements of a
> good project? Both has not to play each other, if they don't like each
> other - but when I see trademark policies growing that might lead into
> stress against DNS Names like our german discussion/supporting board
> where we are active since many years, making cost-free advertisment -
> I'm not amused.
> Protection against opensource vampires is one thing, enforce frustration
> to a community is another.
> 

Agreed. I don't have any background here, so I'll refrain from commenting
further.

> 
>>>> 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,
>> (ie, Icinga doesn't know).
>>
> What do they actual have? Only a few years ago Nagios was just admins
> best friend and not a true accepted competiton to those expensive, non
> scaleable, closed source programs with a bunch of consultans just
> ringing with bells and whistles.
> I personaly never thought about incentive for business before but I
> would say a technology change from c coded cgis to a more open php, a
> function detachment between webinterface (viewing), data collection and
> data source (status.dat, ndo, may be merlin's db, or similar) would be a
> huge improvement for more development and benefits.
> 

It doesn't answer the question. Centreon is, I believe, a PHP-based GUI
for Nagios, but that's not being used. Ninja is nearing completion, and
that too is a PHP-based GUI for Nagios, but that's not being used either.
Your roadmap for the nagios core is laughably vague ("we want to make API
improvements") and it's only the GUI you're talking about but without
mentioning that there are already several existing alternatives to what
you're creating available.

And this is what makes me so sad. I would have hoped that this would lead
to something *good* for the Nagios core, but instead Icinga is causing all
this grief without producing anything that's genuinely new. And you're
doing so behind closed doors. I'm very, very disappointed.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
 http://nordicmeetonnagios.op5.org/

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

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