vanished bug numbers in the nagios mantis tracker

[William Leibzon]

On Tue, Aug 7, 2012 at 12:56 PM, Andreas Ericsson <ae at op5.se> wrote:

> On 08/07/2012 07:24 PM, Jochen Bern wrote:
> > On 08/07/2012 03:21 PM, Andreas Ericsson wrote:
> >> [...] Each module gets to keep its own data and Nagios doesn't need to
> >> know anything at all about it (although it would be neat if it could
> >> issue a callback and get a key/value vector when printing status data).
> > [...]
> >> It would ofcourse be nifty if modules *did* know about each other's
> >> data, assuming they explicitly request it, but that's not what you're
> >> talking about so let's ignore that for now.
> >
> > FWIW (and not that I've ever coded such a thing myself), if two modules
> > would *want* to share data, all they would need beyond the OS' shared
> > memory support would be unique module IDs, a means to coordinate startup
> > priority (so that the module that actually *creates* the shared memory
> > can do so before the "user" modules ask for it), and a means of
> > user-module---to-nagios-core---to-creator-module "hey creator module,
> > hand me the necessary access data!" requests. Assuming that there are no
> > "malevolent" modules you have to protect the same data against, that is.
> >
>
> That is over the top. The idea suggested by John is really good to find
> random module pointers. The using module needs to know about the data
> from the module it uses anyway, and a one-time lookup from all loaded
> modules is no big deal. And the list is already there, btw.
>
> So we'd add something like
>
>   void *nebmod_get_ancillary_data(const char *module_id);
>   int nebmod_set_ancillary_data(const char *module_id, const void *ptr);
>
> to nagios core. The writing module uses the set call. The reader
> module uses the get call. Both provide the same module_id and the rest
> happens automagically.


I think we need more than this. First of even going with above two calls
backs, the call syntax is just not enough - need to be able to ask for data
pertaining to specific service/host/etc and not just by some id. And I'd
rather not have to make an extra call back to get an ephemeral id.

That's why I agree with original thoughts of being able to add "named"
extra data to service/host/etc. And this is not just for use of one module
but something that other modules are expected to be able to ask for. This
allows to extend nagios with modules rather than adding features into core
which is a right way into the future. In fact I'd go as far as advocating
allowing modules to add new config parameters in the future i.e.
registering callback function to process "newconfig = ..." parameters.

And as far as ordering, I don't think it is a big issue. All that is needed
is for nagios to provide a list of loaded or loaded-to-be modules and this
is already created by nagios before modules are loaded. Most of the time
we'll have one module creating extra data and several others who would be
using/reading it; and reading should then happen after initiation when data
is there. Rare case when two modules may want to modify the same data
should either be avoided entirely or synchronization left to those writing
such modules with additional parameters to be passed that specify ordering,
etc.

William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20120807/b4893b30/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel