New Nagios implementation proposal

[nap]

Yep, you are wright, it's nearer a fork than a patch. But before being
a reimplementation proposal, Shinken was a proof of concept for pool
processes and distributed architecture. I already ask core dev what
they think about theses ideas. I ask them in offlist what they thought
about theses ideas because at this time, I did not want Shinken to be
seen as a Fork or something similar. It was just a proof of concept to
prove my ideas was not too stupid, and a C implementation was
possible.

I knew that distributed architecture was hard to accept, but the
process pool was not so hard, it's just a technical problem, not a
user thing.

Ethan just say nothing, Andreas think this is a too big change (the
process pool). At this moment, I knew there was a problem : a process
pool is something threatening in C. In others language? 10 lines and
it's good. If something is so simple in Python, Java, Perl, etc and so
hard in C, we can't evolve quickly.

I know Ethan will not be happy with it, it break its code but it's
still Nagios, just not the same code. I think he will vote 1 (or 4).
But at least he can say it. I try to make a good job for Nagios, a
great enhancement. I do it for all Nagios users, and for new ones
(very big and very little (windows) ones).

I think a good C coder can go into Python very easy. Nagios core dev
are just awesome C coders. Language change is not a real problem.
Change code is. It will take 6 months for reaching Nagios
functionalities, and maybe 6 others months for testing in devel
branch. But after we won't be afraid by Zenoss or Zabbix anymore.
I think this difficult year is not a too hard price for keeping the
number one position of open source monitoring. If core dev do not
think like me, I won't oppose their decisions, they do a great job for
10 years, making Nagios a so good product. If so, I will launch
Shinken as an independant product. Maybe I will just make an epic fail
(can you truly follow a man putting an Obiwan Kenobi option in a
survey? :) ) but at least I try to give to the open source world a
good monitoring product. At least the ideas I put in it will not be
lost (I speak a lot about process poll, but it's not the only one I
put into this code like new options for host/services).

So I vote 3 :)


Jean

PS: thanks for all votes.
PS2: thanks Gerhard, I nearly fall of my chair when I read your mail,
too much laugh with your lick screen ;)

On Wed, Dec 9, 2009 at 11:02 PM, Marc Powell <marc at ena.com> wrote:
>
> On Dec 9, 2009, at 2:50 PM, Flyinvap wrote:
>
>> Le Wed, 9 Dec 2009 12:12:20 -0600,
>> Marc Powell <marc at ena.com> a écrit :
>>
>>> know, Ethan doesn't even know or use Python at all. You are asking
>>
>> And what about taking some concepts from shinken and using their in next
>> nagios versions ? in python, c, c++ or anything else the developers
>> want.
>
> That's not what was proposed but may be encumbered, depending on how Gabès Jean proceeds and under what license. He has contributed very useful code before, particularly the circular parent check logic useful for large installations so I think that he certainly has things he can contribute conceptually and code-wise. As a user with a large installation, I am personally very interested in any changes/additions that improve the performance or capabilities for large installations and fully appreciate the desires expressed by him to implement them. Proposing a complete re-write in a completely different language and asking it to just be accepted might not be the best path.
>
>>> In the end, it's Ethan's decision but I see your project as living on
>>> it's own, similar to Icinga, promoting 100% nagios compatibility, but
>>> a completely different implementation none-the-less.
>>
>> Jean proposed a new implementation for nagios, not a fork, doesn't he ?
>
> If you re-implement something in a language that the current developer does not use, then that is a fork, unless the current developer relinquishes control/responsibility or agrees to switch to that language. Do you know how good Ethan's python coding is, or even if he can at all? To the best of my knowledge whether he can proficiently code in Python is an unknown.
>
>> Is the fork the only solution ?
>
> I think that if Python is the language of choice for the proposed 'reimplementation', then yes, that would be _my_ opinion unless Ethan is fully on board with it and fully involved. I think if the concepts can be integrated into the current codebase, then that's a different thing.
>
>> icinga is not enough ? Is Nagios XI the only future of nagios ?
>
> I don't know and I have no say. Those were just my thoughts and opinions from an end-user perspective with an eye to the time, work and intellectual investment Ethan has in the current code. I do believe that a wholesale replacement of the official nagios with a Python re-write is going to be very very unlikely.
>
> --
> Marc
>
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev