[Nagiosplug-devel] RFC: Plugins config file (final proposal)
gavin at openfusion.com.au
Thu Feb 8 00:21:58 CET 2007
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
> The --default-opts parameter will take a value in the format:
> 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 ....
> 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
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
- 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
> 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
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
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
> If default-opts is not found, return state unknown with appropriate
I think you mean 'config file' rather than 'default-opts' here.
More information about the Devel