Re: [Nagios-devel] New Nagios implementation proposal
Posted: Thu Dec 17, 2009 9:33 pm
--0016e64608487253a6047af35d86
Content-Type: text/plain; charset=ISO-8859-1
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 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.
On Tue, Dec 15, 2009 at 1:53 AM, nap wrote:
> On Mon, Dec 14, 2009 at 1:37 PM, Andreas Ericsson wrote:
> > On 12/11/2009 04:30 PM, nap wrote:
> >> On Fri, Dec 11, 2009 at 1:53 PM, Andreas Ericsson 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.
> Python code just below
>
> 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 ju
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Content-Type: text/plain; charset=ISO-8859-1
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 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.
On Tue, Dec 15, 2009 at 1:53 AM, nap wrote:
> On Mon, Dec 14, 2009 at 1:37 PM, Andreas Ericsson wrote:
> > On 12/11/2009 04:30 PM, nap wrote:
> >> On Fri, Dec 11, 2009 at 1:53 PM, Andreas Ericsson 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.
> Python code just below
>
> 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 ju
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]