> 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 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 =3D {'HOSTADDRESS' : 'address',
[...]
'TOTALHOSTSERVICESOK' : 'get_total_services_ok',
}
The function for the macro resolver just do:
for macrosearch in the_context:
for object in list:
for macro in object.__class__.macros:
if macro =3D=3D macrosearch:
property =3D object.__class__.macros[macro]
Ok, here we find the object that have the macro and we find the
property of this object that have the information. For a simple
property like $'HOSTADDRESS$, the value will be:
value =3D getattr(object, 'property')
getattr is a Python function you can use if you want a property of an
object, but you don't know at the coding phase with one, so at running
time :
getattr(hst, 'address') =3D hst.address
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]