New Nagios implementation proposal

[nap]

Hi,

I was working in the socket return some times ago, but it is not so
fun as I remember when I was hacking Nagios in the past. Seeing this,
I think I will finish this patch, that is a personal challenge, but I
will not make another patch like the rest of the process management of
the queue for modules, sorry (I work at home after work, so it must be
at least a little fun for me).

I still go on with Shinken, making it a real project and all that go
with it like it's own git, site, mailing list, etc. If people want to
test it or just know about it, they can go at
http://shinken-monitoring.org/ and subscribe to the mailing list at
https://lists.sourceforge.net/lists/listinfo/shinken-devel.

I won't make more noise about this project in this mailing list unless
a mix is possible with this two projects. If some want to take ideas
from Shinken for Nagios, go for it, it was it's primer role after all.


Jean


On Fri, Dec 18, 2009 at 2:36 PM, Brad O'Hara <brado at ufl.edu> wrote:
> It's been very interesting following this, but I vote that you work
> together on version 4.
>
> Brad
>
> Andreas Ericsson wrote:
>> On 12/18/2009 12:42 PM, nap wrote:
>>
>>> On Fri, Dec 18, 2009 at 10:49 AM, Andreas Ericsson<ae at op5.se>  wrote:
>>>
>>>>> I'm not saying C/C++ is garbage. I just say we must use them only when
>>>>> need. A scheduler is not a problem to be solved why such low level
>>>>> language. Maybe I am wrong about thinking scheduling is a high level
>>>>> problem. I just need someone to prove it's a low level problem and I
>>>>> will agree with keeping of C code.
>>>>>
>>>>>
>>>> Again, the language is unimportant. It's not hard to write a scheduler
>>>> in whatever language you want, since it's basically just a matter of
>>>> checking what time it is and comparing numbers.
>>>>
>>> Yes, that why I think we must use the easier language for it.
>>>
>>>
>>
>> "Easier" for who? If you really want the perfect language to rewrite
>> Nagios for distributed checking and scheduling you should use Erlang.
>> It was built exactly for that purpose, yet you didn't choose it. Why?
>>
>>
>>>>> Do you watch the code I propose? Can you truly say that you can have
>>>>> such a modularity, performances and distributed usage with C and do
>>>>> not ask another 10years of development?
>>>>>
>>>> Yes. It's perfectly possible to write object-oriented code in C too,
>>>> without the performance penalties that come with an interpreted
>>>> language. Just look at the linux kernel's device driver API and you'll
>>>> see how it's done.
>>>>
>>> "Yes we can" (oups, I forgot the TM) do object-oriented code in C, but
>>> I will be harder than doing it than to use a natural language for it.
>>> The perf penalties are not important here : the major performance
>>> needs are in the checks, not in the core. That why we have the choice
>>> for the development.
>>>
>>>
>>
>> Again, language is only important when it comes to "who can do what in
>> the language used?".
>>
>>
>>>>> (In fact I think it is
>>>>> possible in less that 10 years, but far more than 3). The others like
>>>>> Zenoss are still in the good way. Nagios cannot stay behind.
>>>>>
>>>>>
>>>> That's fairly bullshit imo. With C you can load any other language into
>>>> the core. With Python you're stuck with Python.
>>>>
>>> In fact you can load C (and so whatever you want) :
>>>
>>> import ctypes
>>> libc = ctypes.cdll.LoadLibrary("libc.so.6")
>>> libc.printf("Hello %s", 'World')
>>> Hello World
>>>
>>> It also work on windows dll (but in the Windows platform, it is not magical).
>>>
>>>
>>
>> That's good to know. That means it's possible to write super-fast
>> snippets in C and put that in a Nagios library that the Python
>> thing loads.
>>
>>
>>>>>> and you want more
>>>>>> control over all memory and all data structures, nor do you want to bind a
>>>>>> program to running under an interpreter.
>>>>>>
>>>>> Yes you do not manage memory, but you control your data structure hopefully.
>>>>>
>>>>> For the interpreter problem : how do you install Nagios into Windows?
>>>>>
>>>> You can't just now, but that's mostly because it relies on filesystem
>>>> pipes which windows doesn't support, and the fact that windows performs
>>>> so utterly horrible with multiple processes.
>>>>
>>>>
>>>>> Yes, an interpreter dependency can be a problem (2 installs instead of
>>>>> one, even if Python is installed by default in nearly all Linux
>>>>> distributions...), but if it allows us to do not have to manage low
>>>>> level problem, have a huge portability,  I think use an open source
>>>>> interpreter is not such a problem.
>>>>>
>>>>>
>>>> What low level problems are you talking about? Managing memory? That's
>>>> not really hard in a well-written application with clear API's.
>>>>
>>> But so why is it so hard to create an object? Look at the service creation :
>>>
>>> I don't imagine how many lines we need to add for just add a new
>>> property in service. And the modules recompilation too.
>>>
>>>
>>
>> Because it's not written optimally, ofcourse. A better design would
>> have used macros to recognize, parse and obtain values of the core
>> structures. That way you add new properties in two places. In the
>> structure and once in the struct describing how to parse the value,
>> where you also set rules for valid input. Using macros makes it
>> extremely simple to make a little data go a long way.
>>
>>
>>>>> Yes you can do all of theses things in C, patch the process pool and
>>>>> reaping, but is it the best way of doing it? We must look far more
>>>>> than we do for the moment.
>>>>> A last question (the seventh :) ) : Is the language I propose the
>>>>> problem, or changing habits for developers?
>>>>>
>>>>>
>>>> The language you're proposing is a problem because the current
>>>> developers do not speak it. If you want to go ahead with Python, you'll
>>>> be on your own (to start with) and it won't be Nagios. Sorry.
>>>>
>>> Yep. I begin to think it is not possible.
>>>
>>> I still persist to think we can do much more with higher language in
>>> few months than in years of low level coding. So let's try something :
>>> I work on my own for some times, let's say 6 months (the same time it
>>> took me to get the current code proposal). I will stay in the Nagios
>>> way (same conf, etc). At the end of theses 6 months, let's take a
>>> objective picture of the 2 implementations (with all theirs modules)
>>> and what they propose to the users. Each one can take all ideas of the
>>> other (after all the major part in open source software are ideas, not
>>> codes). At this moment, if I prove that a Nagios code change can be
>>> good for the project, we will look for the best way of merging if it
>>> is still possible. If not, I will stay aside from Nagios and I will
>>> say sorry for all the noise during this few days. We can see this
>>> proposal as a "temporary Fork".
>>>
>>>
>>
>> You're free to fork if you like (although what you've done is  a
>> re-implementation). What you're winning is a chance to have
>> it all your way, language and all. What you're losing is the
>> userbase Nagios has. I'm not saying people won't switch to using
>> Shinken instead, but I think the majority will stay with Nagios
>> simply because it's wellknown.
>>
>>
>>> During this time, please look at Python. I was raised with
>>> emacs/gcc/malloc/gdb/bit masks and printf and I thought that all
>>> others languages were just garbage. I knew I was wrong when I give a
>>> try to Python. It just allow you to concentrate in how fix your real
>>> problem (algorithm or architecture), and not in the preparation for
>>> solving the problem (manage memory, fixed data structure, etc). The
>>> way from C to Python is not so hard. You can still C-style code in
>>> Python (just less (, ) or ;  ) and then try new type of code. You can
>>> still call C code with the ctypes module.
>>>
>>
>> I've already started looking into it. I tend to dislike languages that
>> force an indentation down your throat though, but perhaps I'll just
>> have to get used to it.
>>
>>
>>> Are you agree for a next mailing list meeting in 6 months? All others
>>> core dev too? (I still hope for my Christmas gift :) )
>>>
>>>
>>
>> Why in 6 months? Work with me now and we can make Nagios 4 happen with
>> process pools and distributed checking builtin instead. Isn't that the
>> major gripe right now?
>>
>>
>>>> Why not look into how we can implement the more important parts of
>>>> your design in C instead? It shouldn't really be hard, but I need
>>>> to get time from my boss to help out on that.
>>>>
>>> Yes we can take some ideas for putting them into the code. But it is
>>> not a long term solution. If I'm wrong, we will only lose 6 month and
>>> gain a good competition :)
>>>
>>>
>>
>> Well, creating a new monitoring tool without a userbase or a developer
>> base isn't really a long term solution either. The best program in the
>> world is utterly useless if nobody uses it.
>>
>>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev