[Nagiosplug-devel] Please can I have GIT access

[Jose Luis Martinez]

Thomas Guyot-Sionnest escribió:

>> I see this method as too limiting :S
> 
> I still don't see where you have an issue. Performance data has a very
> specific format and this method doesn't break it (hence the "Only small
> numeric values can be passed" Cons. I've been using this method
> successfully for some time now.

I'm not saying this method can't be succesfully used, and think it's 
really clever! It actually inspired the token techinque.

I think it's too limiting because:

  - you don't always calculate the next data with the perfdata you output
  - it's only valid for numbers
  - the size of the perfdata is limited
  - you may want to store multiple results and not just the last result

I don't see this method of storing data as a flexible long term solution 
for saving plugin state in Nagios plugins, although it can be used 
effectively and flawlessly in some scenarios.

> 
>> I would be open to adapting Nagios::Plugin::Differences to also support 
>> the use of FD's as a pluggable storage mechanism, it shouldn't be too 
>> complex (was already planning for pluggable storage)
> 
> As you wish... though IMHO I think we should settle on a single method.
> and use it. Even if we go file-based, the advantage with a perl module
> is that you can allow using different modules for storage given a
> specific API. In other words, anyone could write it's own data storage
> module and plug it in directly. You could use some sort of "connection
> string" (referring to the perl DB API since It has similar purpose) that
> would allow selecting the storage method using a parameter from
> command-line options.

On the C side, you guys know better. On the Nagios::Plugin::Differences 
side:

If the Nagios Plugins project goes for wrappers or FD passing: 
Nagios::Plugin::Differences will try to support it.

Since in Perl it's so easy to let the developer choose, I'd still let 
them choose if they want to store via FDs, or the multitude of storages 
available on CPAN (also, the non-FD storage would be available right now).

> Or another option, write a brand new plugin API which is much more
> extensible and allow passing specific values (besides output and
> performance data) back to Nagios. Most people think of XML though I
> believe it's up for debate - there are simpler and smaller solutions
> IMHO, and I believe Andreas agrees with me on this ;)
 >
> Obviously that's a big change; It won't be done quickly nor easily so
> there mucg be strong incentives and community support for this to happen.

I'd opt for the almost already available than for the new bright and 
shiny that never comes. More so if what is almost here provides the same 
functionality :)

Either way you choose to implement the storage on the C side, I 
understand there is one common problem: binding to a service. If that 
gets studied, discussed, selected and implemented quickly the APIs will 
be able to provide surprise-free operation by default.

Can you expose how you were thinking of modifying Nagios and the remote 
executors?


Jose Luis Martinez
jlmartinez at capside.com