New Nagios implementation proposal

[Andreas Ericsson]

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.

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