New Nagios implementation proposal

[Anthony Montibello]

Hi List,

I think the concept does have value, however the core team is likely to be
looking at the maturity of the existing code ,as well as, the complexity of
integrating something like this into the core.

Threads do exist in C (pthread) However threading should NEVER be "Just 10
lines of code and All good."  Synchronization, reliability, logging and
extra bookkeeping (just in case); will  always take more effort  in
multi-threaded apps,  attention to the potential Critical code blocks,
mutexes/monitors, limited resources, thread racing and starvation are
difficult to debug. particularly when using code managed by a virtual
machine (like Java)

On the Language of choice, it is important to remember that C is a mature
and stable language that is low level.  being a mature language it has less
bugs than some of the newer languages (like Dot Net).  All new languages
take time to become stable and an application like Nagios  ( in my opinion)
should never be ported to a language that gets upgrades ever three months. I
am not familiar with Python, or any of its administration needs.  I have
seen in less mature language on major version changes functionality drooped
or modified forcing rework on existing code that was originally bug free.

Is it possible to maybe merge Shinken concept into Nagios as a compilation
option?  or is that just to complex to merge? Is it posible to put together
some flow charts/outlines as to what it would take to merge this model into
the existing Nagios progect?

Tony (Author of NC_Net )




On Thu, Dec 10, 2009 at 4:33 AM, nap <naparuba at gmail.com> wrote:

> 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
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20091210/ca05c3e2/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel