atom feed37 messages in net.sourceforge.lists.nagios-develRe: [Nagios-devel] Nagios is dead! Lo...
FromSent OnAttachments
Gerhard LausserMay 6, 2009 2:58 am 
Christoph MaserMay 6, 2009 3:54 am 
Andreas EricssonMay 6, 2009 4:13 am 
Alexander WirtMay 6, 2009 5:53 am 
Hendrik BaeckerMay 6, 2009 5:58 am 
Andreas EricssonMay 6, 2009 7:12 am 
Andreas EricssonMay 6, 2009 7:48 am 
Ethan GalstadMay 6, 2009 8:55 am 
Steven D. MorreyMay 6, 2009 9:27 am 
Haydn solomonMay 6, 2009 11:21 am 
Mathieu GagnéMay 6, 2009 11:33 am 
Matthias FlackeMay 6, 2009 11:56 am 
Steven D. MorreyMay 6, 2009 12:25 pm 
Jeremy HanmerMay 6, 2009 12:59 pm 
Andreas EricssonMay 6, 2009 1:47 pm 
D. Emmanuel FeinsmithMay 6, 2009 2:15 pm 
Steven D. MorreyMay 6, 2009 2:48 pm 
Andreas EricssonMay 6, 2009 3:42 pm 
Matthias FlackeMay 6, 2009 3:45 pm 
sean finneyMay 7, 2009 12:22 am 
Albrecht Dre?May 7, 2009 2:15 am 
matthias ebleMay 7, 2009 2:19 am 
Andreas EricssonMay 7, 2009 2:22 am 
Andreas EricssonMay 7, 2009 4:32 am 
Andreas EricssonMay 7, 2009 7:07 am 
Ingo LantschnerMay 7, 2009 7:57 am 
Hendrik BaeckerMay 7, 2009 9:52 am 
Hendrik BaeckerMay 7, 2009 10:31 am 
Mathieu GagnéMay 7, 2009 12:21 pm 
Bernd ErkMay 7, 2009 12:23 pm 
Andreas EricssonMay 8, 2009 12:19 am 
Andreas EricssonMay 8, 2009 12:30 am 
Andreas EricssonMay 8, 2009 12:42 am 
Julian HeinMay 10, 2009 12:50 pm 
Mark...@teliasonera.comMay 26, 2009 1:48 am 
Andreas EricssonMay 26, 2009 3:21 am 
Mark...@teliasonera.comMay 26, 2009 3:44 am 
Subject:Re: [Nagios-devel] Nagios is dead! Long live Icinga!
From:Hendrik Baecker (andu@process-zero.de)
Date:May 7, 2009 10:31:59 am
List:net.sourceforge.lists.nagios-devel

-----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? If so: What if you get users with smaller environments which won't profit of the pure merlin power?

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.

No they won't for the first steps. We know that there are many good ideas out there to make the nagios core (scheduling, object handling and so on) better. Like the historical IPC stuff died from version 2.x to 3.x, we hope that other historical code segments will be replaced in the future. I think Ethan never thought of 20000 services environments and such a huge community 5, 7 or 10 years ago. Will say: It's not bad but it might be better.

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?

Right.

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.

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.

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.

Regards, Hendrik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoDGyYACgkQlI0PwfxLQjlstACeIpfWII+BmyAedSTvTWgADinO ktAAoIN/bYpNbaEm/KtjhQt2llQxuOz8 =bUcM -----END PGP SIGNATURE-----

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