New Nagios implementation proposal

[nap]

On Fri, Dec 18, 2009 at 10:49 AM, Andreas Ericsson <ae at op5.se> wrote:
> 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 begin to think so.

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

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

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

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

/* add the service */
new_service=add_service(this_service->host_name,this_service->service_description,this_service->display_name,this_service->check_period,this_service->initial_state,this_service->max_check_attempts,this_service->parallelize_check,this_service->passive_checks_enabled,this_service->check_interval,this_service->retry_interval,this_service->notification_interval,this_service->first_notification_delay,this_service->notification_period,this_service->notify_on_recovery,this_service->notify_on_unknown,this_service->notify_on_warning,this_service->notify_on_critical,this_service->notify_on_flapping,this_service->notify_on_downtime,this_service->notifications_enabled,this_service->is_volatile,this_service->event_handler,this_service->event_handler_enabled,this_service->check_command,this_service->active_checks_enabled,this_service->flap_detection_enabled,this_service->low_flap_threshold,this_service->high_flap_threshold,this_service->flap_detection_on_ok,this_service->flap_detection_on_warning,this_service->flap_detection_on_unknown,this_service->flap_detection_on_critical,this_service->stalk_on_ok,this_service->stalk_on_warning,this_service->stalk_on_unknown,this_service->stalk_on_critical,this_service->process_perf_data,this_service->failure_prediction_enabled,this_service->failure_prediction_options,this_service->check_freshness,this_service->freshness_threshold,this_service->notes,this_service->notes_url,this_service->action_url,this_service->icon_image,this_service->icon_image_alt,this_service->retain_status_information,this_service->retain_nonstatus_information,this_service->obsess_over_service);

I don't imagine how many lines we need to add for just add a new
property in service. And the modules recompilation too.


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

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.
If we were speaking about coding a kernel module, I will just speak
about C. But it's not the case.

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


Jean

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