[Nagiosplug-devel] [Nagiosplug-help] check_ntp

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/11/07 09:01 AM, Ton Voon wrote:
> On 15 Nov 2007, at 18:05, Thomas Guyot-Sionnest wrote:
> 
>> I'm fine with the names Andreas suggested except that I'd remove  
>> the "s"
>> from check_ntp_peers as it only check one peer (my initial  
>> suggestion if
>> you didn't read the whole thread was "check_ntpd").
> 
> I'd vote for check_ntp_peer, but it's your change, so you have  
> casting vote!

I like check_ntpd but I agree it can be a bit confusing...
check_ntp_peer and check_ntp_time seems to be the best consensus for
everyone incl. myself so let be it.

>> I'd like to start a more in-depth document called RELEASE_NOTES or
>> something like that that would explain all the changes that might  
>> affect
>> users. This way we should keep all entries in NEWS one-liners and have
>> more space to communicate the possible issues and gotchas.
>>
>> Just like NEWS it would cover all previous releases, so someone
>> upgrading from an old release could just go tough the release notes  
>> for
>> each releases in-between.
> 
> Not sure what this buys us, as it sounds like duplication. What about  
> the one-liner being like heading and then the more descriptive text  
> underneath? Then for official releases, I'll just take the headings  
> and put that in the news article.
> 
> The heading should say if there is an incompatibility so then you  
> would read the NEWS file for more details.
> 
> For example:
> 
> Incompatibility: check_ntp replaced with check_ntp_peer and  
> check_ntp_time
>    check_ntp had two distinct functions which are now separated out  
> for clarity...{extra technical stuff}...check_ntp will be deprecated  
> in the 1.5 release.
> 
> I'm thinking that the sourceforge download should have the full NOTES  
> for that release, but any publicity will just have the headline.

Ok, sounds good too. Shall I use tabs or spaces (2?) to intend the
detailed text? I'm personally fine with tabs since I set the tabstop to
two (and my console windows are 160 collumns anyways) but I won't force
it upon anybody... :)

>>> We can cut a 1.4.11 release as this should be out as soon as  
>>> possible.
>> If it's about the two security fixes we could just make a butfix  
>> release
>> with them and have more time to work on 1.4.11. There's also a bug in
>> processing N::P .ini arguments. I posted a patch some time ago but  
>> since
>> my code is much simpler I felt like I could have overlooked  
>> something so
>> I didn't commit it.
>>
>> I'll reply to myself about that as it seems that it was missed. It  
>> would
>> be nice to have a newer N::P out at the same time and included in the
>> newer release.
> 
> If it will only take another week, I think we can hold off 1.4.11 and  
> the security fixes for the same release.

Well, guess what... I need to either change max_state to have UNKNOWNs
above OKs or revert part of one of my patch... The max_state change
shouldn't be a big deal but I'll have to review all plugins and make
sure they don't assume that (Like check_ntpt that initially set its
states to unknown and then used max_state to "increase it" to OK, WARN
or CRIT).

This should be done within a week (actually tonight is I don't fall
asleep...)

>> Considering the lifecycle of 1.4.x, 1.5 is pretty much a major  
>> release.
>> I'm good for making it a dummy check in 1.5.
>>
>> While we're at it, it will soon be a good time to branch 1.4.x and  
>> start
>> working on 1.5. You should do that as soon as you publish your roadmap
>> (below).
> 
> I keep delaying it, but one thing I realised when I was writing the  
> slides for the Netways conference was that I'm a bottleneck for a lot  
> of activity. I'm going to fix that. First start here: http:// 
> nagiosplugins.org/roadmap

No worry; I think we were all very busy last months and that's why
things are going slow... I don't feel like you slowed things much.

I just looked at it and I think we shouldn't look much into the .ini
stuff for now until Holger shows his plans for a new internal C library
since the ini stuff will likely go there and not directly into plugins.
If you're on a hurry to push 1.5 then maybe Holger's plans and the C ini
stuff should go on 1.6. In the meantime we should work on standardizing
everything (using thresholds and perfdata functions for example) so that
larger-scale change we plan for the future will integrate seamlessly.

Finally I'd be pleasantly surprised if we follow the current timeline of
this document, but unless we get more developers or more time I doubt
they're much realistic. IMHO we should also reserve some developer time
on enhancing current plugins and/or adding new ones. What we're heading
to is really great for the future of Nagios-plugins but it doesn't add
much value to the users in the short term. Some of the other things I
have in mind:

- - Some fixes on check_http (handling of redirects and possibly others)
- - enhancing check_file_age (I actually want to rename it to check_file
with a backward-compatible check_file_age symlink - will look in time if
it can work)
- - Perform checks trough SOAP calls (check_by_http?)
- - Add a MSSQL check (much asked feature and I have one 99.9% ready).
  * As I was writing this I just realized we have one (why didn't I see
that???), but mine have more features.
- - Look for more interesting feature requests in the tracker.

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHPpkW6dZ+Kt5BchYRAi+zAKDMWGSsZTcwY6PyiAQE8wRGAq+JpACghDnZ
HWeQIB+GGzaDxmyfejisfHQ=
=ZcGR
-----END PGP SIGNATURE-----