[Nagiosplug-devel] Nagios plugins CPAN-like archive (was: Obsoleted contrib and tarballs files)

[Ton Voon]

On 12 Jul 2005, at 03:59, sean finney wrote:

> hi,
>
> On Mon, Jul 11, 2005 at 11:10:35PM +0100, Ton Voon wrote:
>
>> No opinions about a Nagios plugins CPAN-like area? I'm interested to
>> hear what people think. Please respond privately if you prefer.
>>
>
> i think providing an easier way for people to submit and review
> plugins is a good idea.  i do have some concerns though:
>
> my main concern is with qa-related topics.  sure, there's the NIH
> syndrome you mentioned earlier (which i think is relevant), but i'm
> more worried about the overall lack of control over quality, as well
> as pollution of our namespace/reputation.

Hadn't thought of the namespace situation. CPAN does have control  
over what namespace perl modules can take, at least at a top level.  
Not sure how this would work for plugins, which is just a single file  
name... Any ideas on controlling this? Or is it even a problem?


>
> i think such concerns could be addressed if we had some way of  
> providing
> some kind of nagiosplug "status" or "rating", where it was made clear
> whether or not it was reviewed by a member of the team, whether it was
> being considered for inclusion, et c.  if such a system existed, i  
> think
> it would make a better bridge for plugins to make their way into the
> project, and would overall be a good thing.

I like CPAN's rating system. It is not fully used, but it gives a  
good general feedback on the quality of a perl module from the users.  
I'll add to my wish list.

As for quality, I was thinking that there are varying levels of  
"certification" for a plugin (this is based on an email thread a long  
time ago, which I can't recall which). I propose that the dev guide  
should show level 1 as "returns 0 OK, 1 warn, 2 crit, with one line  
output", --help/-h with output, --version/-v for version info. Level  
2 is perf data. Level 3 is stuff like -v -v -v for extra debug  
options and internationalization. Level 4 is stuff to do with  
integration into core (using common libraries, etc).

With some work on the new test harness, I think we could probably  
create a generic test harness which proves which certification level  
a plugin is at.


> this would also obsolete
> the need for a "contrib" section.
>
> otherwise, i'd be very hesitant for moving in this direction, and am
> not sure what it would gain us that couldn't be simply done by linking
> to the nagiosexchange site where a similar collection system for  
> plugins
> already seems to exist.

I'm trying to work out our requirements for the NP collection system.  
Then I plan on having a discussion with Nagiosexchange, where I'll  
find out if they can meet all the requirements we have, in return for  
us officially promoting the use of their site. Seems like a win-win:  
we'll get what we want, while they gain exposure.

It could be that we decide to keep it in house and develop our own  
collection system, which is valid (for instance, control of namespace  
could be a major issue). But then I really need commitment that we  
can do this ourselves!

Ton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20050711/607d4f34/attachment.html>