New Nagios implementation proposal

[Andreas Ericsson]

On 12/18/2009 08:55 AM, nap wrote:
> On Thu, Dec 17, 2009 at 10:32 PM, William Leibzon<william at leibzon.org>  wrote:
>>
>> I happen to agree with making nagios more modular and I don't think thread
>> pool is architecturally a bad idea either. I don't think its necessary to
>> rewrite everything to implement this, it could be a significant rewriting
>> effort that would improve or replace large parts of nagios base code while
>> retaining parts that are ok.
>>
>> I disagree about ideas to entirely rewrite nagios and do it in something
>> other then C/C++. The "features" mentioned for Python are just tools, they
>> can all be available with additional C/C++ libraries or with classes or
>> functions we can write ourselves.
>> And while its faster to do a script or
>> prototype in Perl or Python because of features like named arrays, built-in
>> regex expressions and because debugging interpreted language is much easier,
>> for large project these are not necessarily an improvement
>
> Not an improvement to allow easy portability?

It's not hard to write portable C-code.

> Not an improvement to
> allow to someone to code a new database export in one day?

I could do that in C, but not in python.

> I think use
> the adequate language is important. Nagios need portability,
> performances in launch checks (the rest of it's job is just nothing in
> the performance point of view), easy distributed usage. Yes python
> features are tools. But tools for easy development, and give us time
> to think about true problem like algorithms (do you remember the
> parent check problem? Or still the reaping of flat files.) or
> architecture. I think we can go thurser by thinking about theses
> problem instead of thinking "Did I do the free() in the good
> function?".
> 

I think the language is utterly unimportant, so long as its one many
developers feel comfortable with. If you want to move forward with
Python, you'll have to make your own project out of it. I'm not
saying that would be a bad idea. I'm just saying it almost certainly
won't happen within the Nagios project as such.

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

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

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

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

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

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.

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