[Nagiosplug-devel] RFC: New threshold syntax

Andreas Ericsson ae at op5.se
Thu Mar 20 14:23:50 CET 2008


Max wrote:
> On Wed, Mar 19, 2008 at 10:59 AM, Andreas Ericsson <ae at op5.se> wrote:
>>  Not really. Verbose and easy to read should win out any time, as the
>>  syntax isn't supposed to be used daily. It's much more important that
>>  it's accurate and that the user is comfortable with the thresholds
>>  he/she has specified than that it's possible to cram as many args as
>>  possible into an 80 char wide screen.
> 
> What are your suggestions, Andreas?  You have given a lot of feedback
> on what you like and do not like, what syntax do you suggest?
> 

See the other fork in this thread.

> 
>>  I am, in the strongest possible terms. For one simple reason: Bitrot.
> 
> Let usage show who wins, provide a few parsing options, see which gets
> used the most and then drop the others as officially supported and let
> people from the Nagios user community support them if they are wanted.
> 

Except for one rather large problem there; Content users usually keep
their voices down, while the angry ones voice their complaints. So we
go with two sets of options, then remove one because we guess (or even
do it properly and set up a user-survey) to see which one is most popular.
Then we remove the other and find that there were thousands of users who
now got bitten because their configurations stopped working all of a
sudden. They'll all come to nagiosplug-help@ (or nagios-users@) to
ask/complain/spew gaul/whatever, and someone will have to deal with that.

> 
>>  Not stupid, but naive if you think that both of them will be kept up
>>  to date, along with the documentation for both of them. Like I said,
>>  it's maintenance nightmare to support two different ways of saying the
>>  same thing, and doubly so if you want users to know about it.
> 
> I do think that if their is enthusiasm among Nagios users to keep them
> up, they will be kept up and Nagios is all about choice - flexible
> syntax, loads of add-ons and enhancements and points of integration.
> 

Perhaps there is enthusiasm, but most of the plugin users are admins,
not programmers. If we were catering to kernel hackers, I wouldn't
be worried at all, but we're not.

> No one would expect you to maintain them, you do not think there are
> enough Nagios plugin writers available to support two parsers?
> 

That's exactly what I think, because you can't even add options to
a plugin then without having to know both parsers enough to add
a way to set those options for the plugins in either way. I believe
this raises the itch-to-contribution barrier significantly, and as
such it will only do the plugins project harm.

>>  What about use?
> 
> I agree, present a few options and let 'use' decide which wins in the long term
> 

*sigh* There will still have to be flag-days for when we deprecate the old
syntax (in plugins-2.0, I expect, as it will no longer be backwards compatible),
and then it'll have to be a new major release when we drop support for whichever
way of specifying arguments happened to not win.

Ton, are you up for doing 2 flagdays in one year, or even half a year, with
all the user-hassle it usually means?

op5 will probably help writing conversion scripts for peoples configurations,
but if we're the only ones that do that, we'll effectively end up picking the
"most popular syntax", so that's an entirely new dilemma right there.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231




More information about the Devel mailing list