Re: [Nagios-devel] New Nagios implementation proposal
Posted: Thu Dec 17, 2009 9:00 pm
_________________________
------------------------------
\
=A0\
=A0 \ >()_
=A0 =A0 =A0(__)__ _
_______________________________
--------------------------------------
\
\
____
/# /_\_
| |/o\o\
| \\_/_/
/ |_ |
| ||\_ ~|
| ||| \/
| |||_
\// |
|| |
||_ \
\_| o|
/\___/
/ ||||__
(___)_)
but there was still one person to do not answer to my mail. It was my
birthday some days ago, but still no mail, maybe I will get one for
Christmas?
!
-~*~-
/!\
/%;@\
o/@,%\o
/%;`@,\
o/@'%',\o
'^^^N^^^`
[+OK ready\nUSER naparuba\nPASS blabla] 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 =A0wrote:
>>>
>>>>
>>>> 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 cla
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
------------------------------
\
=A0\
=A0 \ >()_
=A0 =A0 =A0(__)__ _
_______________________________
--------------------------------------
\
\
____
/# /_\_
| |/o\o\
| \\_/_/
/ |_ |
| ||\_ ~|
| ||| \/
| |||_
\// |
|| |
||_ \
\_| o|
/\___/
/ ||||__
(___)_)
but there was still one person to do not answer to my mail. It was my
birthday some days ago, but still no mail, maybe I will get one for
Christmas?
!
-~*~-
/!\
/%;@\
o/@,%\o
/%;`@,\
o/@'%',\o
'^^^N^^^`
[+OK ready\nUSER naparuba\nPASS blabla] 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 =A0wrote:
>>>
>>>>
>>>> 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 cla
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]