New Nagios implementation proposal

[nap]

On Fri, Dec 18, 2009 at 2:03 PM, Andreas Ericsson <ae at op5.se> 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?
For the Erlang :
https://www.ohloh.net/languages/compare?commit=Update&l0=c&l1=python&l2=erlang&l3=-1&l4=-1&measure=commits&percent=true

I think the Erlang can be more than useful for the distributed part
but for all others parts (like for modules and database exprot) the
lack of modules (and coders) can be a real problem.

>
>>>
>>>> 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.
Yes. Some games are made like this : Higer part (logic and co) are in
higher language (Python, LUA, etc) and lower part are in C/C++ (opengl
and picture manipulation).

>
>>>
>>>>> 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 but such a modification need a lot of rewrite in xdata/*c.

>
>>
>>>
>>>> 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?
OK. Let's do that :)
I will keep my implementation as a proof of concept and quick specs
validations for some things I think about (like critical_is_warning,
hot_periods, or inverse_ok_critical that I will speak about in the
next mail) or the realm role in the distributed environment.

I think the distributed is a Merlin things (unless you want to make
the distributed capability a core functionality) and we can speak
about it in the merlin list. Maybe we can look if a distant object lib
can be used to factorize code.


>
>>>
>>> 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.
True. But a stagnant open source program is a dead one too. I think we
shouldn't be so sure that Nagios users will always be Nagios users.
This discution show us that quite a lot of people want Nagios to go on
and not just stay in it's current glory.


>
> --
> Andreas Ericsson                   andreas.ericsson at op5.se
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
>
> 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.
>
> ------------------------------------------------------------------------------
> 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