[Nagiosplug-devel] RFC: Plugins config file (final proposal)

[Gavin Carr]

Hi Ton et al,

I've made a start on implementing this within Nagios::Plugin. Should 
have first-pass code in CVS today.

A few questions as I work through the RFC:

On Wed, Jan 31, 2007 at 12:50:02PM +0000, Ton Voon wrote:
> PROPOSED SOLUTION
<snip>
> 
> The --default-opts parameter will take a value in the format:
> 
> --default-opts=[stanza_name][@config_filename]
> 
> If stanza_name is missed out, will assume stanza_name = plugin name.
> 
> If @config_filename is missed out, will search for the configuration
> file in default locations.

And the default configuration file name is ....

plugins.cfg?

> IMPLEMENTATION DETAILS
> 
> The C routine is to be called np_getopt_long and has the same  
> interface as getopt_long (from gnulib).
> 
> The perl routine in Nagios::Plugin will not require any changes at  
> the plugin level.
> 
> Both the C and the perl routines do not require specification of -- 
> default-opts to process that option - it is implicitly checked and  
> processed.

Ok. Three things:

- for packages, we probably want to make sure we ship with an empty
  (or all commented out) config file, because otherwise I imagine we'll 
  get some very confused people wondering where these 'magic' extra 
  options come from

- does a --default-opts=foobar override this implicit check? i.e.
  we don't check --default-opts=plugin_name if --defauult-opts=foobar
  is set?

- how do we turn this off? e.g. if I've got some default options
  defined for a random plugin in the [plugin_name] stanza, how do I 
  do a special invocation _without_ those options? I can't do
  --default-opts=bogus, because that's an error. Do we need a
  --no-default-opts?

> When processing options, there needs to be a first pass to extract  
> all the --default-opts options and process the config files.  
> Duplicate config options are removed, last one wins. Any options on  
> command line will remove the default.
> 
> Duplicates removal would include equivalent short and long options.  
> For instance, a default config file of username=manager with a -u  
> admin on command line would produce the equivalent of -u admin.

I'm not sure about this duplicate removal stuff, on two fronts:

1. I think duplicate arguments might be useful sometimes. e.g. how
   about a plugin that takes a --path argument, indicating places
   to search for some file. Allowing multiple paths do be defined
   additively (some default, some test-specific) seems very nice
   behaviour.

2. It significantly complicates the processing, and it requires that
   the we _understand_ the arguments (especially the shortname/longname
   equivalence). I think it's cleaner if the default-opts handler can
   just be dumb, load all the arguments from the config files, and
   dump them on the front of the argv list to be processed. It's then
   handled by the conventional argument processing as defined by the
   plugin, rather than removed by fiat. i.e. if your plugin says
   multiple usernames are okay, you get them all; if it says username
   is single, the argument processing only gives you the last one.
   Is that sufficient/acceptable?

> The order of the options is not guaranteed - defaults maybe added at  
> beginning or the end of processing. If you want to use options that  
> could be positional dependant (such as check_disk's -p), it is  
> recommended to avoid --default-opts.

Again, I'm arguing for a simpler approach here. I'd like to just say
something like:

  Groups of default options are prepended to the argument list in 
  the order in which they are defined i.e. using '--default-opts=A 
  --default-opts=B' will cause all options in A to occur first, then
  all options in B, and then all other options. The order of options
  _within_ a config file stanza is not defined, and should not be
  relied upon.


<snip>
> If default-opts is not found, return state unknown with appropriate  
> message.

I think you mean 'config file' rather than 'default-opts' here.


Cheers,
Gavin