New Nagios implementation proposal

[nap]

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? Not an improvement to
allow to someone to code a new database export in one day? 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'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.

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

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

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?


Jean

>
> On Tue, Dec 15, 2009 at 1:53 AM, nap <naparuba at gmail.com> wrote:
>>
>> On Mon, Dec 14, 2009 at 1:37 PM, Andreas Ericsson <ae at op5.se> wrote:
>> > On 12/11/2009 04:30 PM, nap wrote:
>> >> On Fri, Dec 11, 2009 at 1:53 PM, Andreas Ericsson<ae at op5.se>  wrote:
>> >>
>> >>>
>> >>> Process pools aren't that hard to do in C really, but altering the
>> >>> entire concept of how Nagios operates is a fairly big change. OTOH,
>> >>> I'm
>> >>> not thrilled about the whole "check-results are stored in tempfiles"
>> >>> thing either, and *that* was a major change too.
>> >> Maybe we can first work in the "return in socket/memory" before try
>> >> the process pool. It must be easier and can have very huge effect.
>> >>
>> >
>> > That would be easier, yes. I once did a test of multiplexing check
>> > results and had very good results with it. The only problem is that
>> > it would require a double-fork() now, as checks would have to be
>> > wrapped in something to provide correct output with the microsecond
>> > execution time precision Nagios currently uses.
>>
>> I don't understand the double-fork problem : whereas writing a flat
>> file, the son who popen the check just open a socket to the nagios
>> main process. Unstead of micro-sleep, nagios must select (just timeout
>> instead of sleep) the socket. It must put in queue the result for
>> reaping or maybe direct reap this result.
>>
>> >
>> >>>
>> >>> Jean, let's discuss how we can move this forward within the C-code
>> >>> in such a way that we retain compatibility on all levels. Too many
>> >>> have invested too much in Merlin, NDOUtils and other C-based addons
>> >>> to relinquish them easily, and splitting the community again would
>> >>> be really, really stupid.
>> >> I'm agree with it. But I also think we cannot avoid a lot of years a
>> >> re-factory in order to use new tools like distributed object
>> >> technologies or dynamic development (you create properties for your
>> >> object, so you cut a lot part of your code). I know we can make greats
>> >> things in C. We will make great things in C for V4. But we must think
>> >> about long term development too.
>> >>
>> >
>> > Well, we could probably rewrite Nagios from scratch in a lot less than
>> > a year. Like most great things, it's not the implementation that's so
>> > spectacular but the idea behind it that is brilliant.
>> Yes
>>
>> >
>> > I have no idea what you mean by "dynamic development". It's a hypeterm
>> > that can mean anything from "we let quality fluctuate wildly" to "we
>> > never really know what features the next release will hold". It's
>> > hardly ever anything good anyways.
>> <Warning> Python code just below :) </warning>
>>
>> Believe me, I do not use this term in a marketing way. I just HATE the
>> marketing : you thing buy the best tool of the world, and in fact it
>> just do nothing the guy who sent it to you says. Here the dynamic is
>> not for the dynamic of the project or something like this. It's just
>> the capacity of Python for code introspection.
>>
>> You can "attach" arrays in classes. You can also access class of an
>> object just by object.__class__. I use this in the macro resolver
>> part. I use one function to resolv a command, it take the command line
>> (with macros) and a list of object. It just do not care about with
>> object it is, it can be host, service, contact or whatever you want.
>> Let called this list "the context". Importants classes like hosts,
>> services or contact have a macros arrays : it list available macros
>> for the type and for each macro the property of the object that have
>> the information. For host we've got for example :
>> macros = {'HOSTADDRESS' : 'address',
>> [...]
>> 'TOTALHOSTSERVICESOK' : 'get_total_services_ok',
>> }
>
> ...
>
>
> ------------------------------------------------------------------------------
> 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