[Nagiosplug-devel] check_maxchannels for perl framework

[Stanley Hopcroft]

On Wed, Mar 31, 2004 at 09:42:21AM +0100, Howard Wilkinson wrote:
> Stanley,
> 
> I intend to produce a design/suage document shortly. It will be small 
> with dot points if I can get it out shortly. The rational for this 
> approach is 2 fold.

>  Adding the burden to the plugin writer to produce 
> the output of the usage, help, version and other standard function in a 
> consistent and complete fashion seems to me to be unnecessary which has 
> led to the thinking that perhaps a framework for the entire operation of 
> a plugin would be a good idea, which has led to this approach being 
> adopted.

Unfortunately, I don't find this a compelling reason largely because 
usage, otions help etc are so easy to change and far less important than 
the check logic.

Constructing a Perl plugin can be currently done by

1 replacing the check logic in an existing plugin

2 replacing the option processing  

3 replacing the usage information to reflect the new options and plugin 
function.

4 replacing the help info as for 3.

I agree that this approach provides no consistency between options, help
and usage but don't find inconsistencies costly.

OTOH, with this proposal I will have to abandon my investment in 
learning the Getopt:: modules and learn this one.

In fact, using an accessor usage ($obj->usage("foo")) sounds harder than
editing the text in sub print_usage, although after I have one with the
new framework, my editing will be similar to that above (but in less
familiar places).

In principal, the new framework simplifies option processing, but this 
is an area that does not cost nearly as much as the service check logic.

What at least seems evident without much looking at the code is the new 
framework eliminates or reduces the cost of option checking by 
associating edit checks with the options. 

The other neat thing appears to be the timeout processing. I don't
understand how it does it but it seems neat to avoid thealarm($TIMEOUT);  
eval { #time sensitive op }; alarm(0); stuff.


> The second is the thing that got me started on all of this, 
> which was needing to get consistent, complet and upto date usage 
> information and help information in machine processable form for entry 
> into a database. This database is then used to provide a user interface 
> that can prompt for data from the user when building Nagios 
> configurations. I need to be able to do type checking, provide value 
> checks where possible, confirm that parameters will be compatible (e.g. 
> SNMPv1 with SNMPv3 authorisation arguments do not make much sense) and 
> so on.
> 
> Thus, I am led to the approach shown in the Plugin and Plugin::Parameter 
> modules. Probably coudl be done better, could certainly use Perl smarter 
> and give more consise files (but probably not faster executing)

You could generate the accessors but as you say this will save source
length without probably impacting parse/run time. OTOH, it may be a 
maintenance faciltator (see 'Sufficiently encapsulated hacks' by Michael 
Schwern).

> but it 
> does have some industrial strength and will if finished provide a much 
> easier environment within which plugins of greater content can be 
> written. 



> I am working on standardising the SNMP framework to allow the 
> writer to concentrate on processing the MIB results, as well as, 
> providing a common error reporting framework and output production 
> framework.
> 
> On a note I received from Karl and have responded to but is related to 
> peerformance. Our exeperience so far is that this has little eimpact on 
> a running monitor environment, where about 50% of our plugin executions 
> have now been changed to operate this. The cost of loading the Plugin 
> could be reduced considerabley if the POD is removed from the Plugin.pm 
> and Plugin::Parameter.pm files - this could be done at compile time by 
> fixing the Makefile. This would reduce the file size by > 50% thus the 
> overhead is about 35K source code. Further pounding on my style could 
> easily bring this down by 50% so for smaller machines we could make this 
> a not problem.


Style and POD are I think irrelevant to speed since both of these are 
thrown away by the lexer. I like spaces; I usually understand those 
bits.

The performance penalty will be in the extra subroutine calls.

Anything you can inline in a module is worth it.

> 
> I have not tested under ePN although I believe I have stuck to the rules 
> for compile once, run many operation.

I can't see any obvious ePN problems although I am worried about taint 
checking for reasons that I can't recall.

Try your plugins with contrib/mini_epn _more than once_  to get a basic 
feel for their compliance.

> I would appreciate some live 
> running under ePN by someone and some feedback on what to fix, as we 
> will be implementign an ePN based environment later this year and I 
> would like to concentrate on getting working and not the plugin's.
>

If you A B them with the dotime program posted formerly, you will know 
precisely the difference between the old framework and the new.

 
> Another note. All of the plugins now have taint checking on by default, 
> and have been fixed to work in this environment.
> 

One last comment, is that there are still folks using 5.005; you may 
want to consider replacing our by my.


> Regards, Howard.

-- 
------------------------------------------------------------------------
Stanley Hopcroft
------------------------------------------------------------------------

'...No man is an island, entire of itself; every man is a piece of the
continent, a part of the main. If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friend's or of thine own were. Any man's death diminishes
me, because I am involved in mankind; and therefore never send to know
for whom the bell tolls; it tolls for thee...'

from Meditation 17, J Donne.