[Nagiosplug-devel] [Nagiosplug-help] check_ntp

[Thomas Guyot-Sionnest]

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

Ton Voon wrote:
> Hi!
> 
> Sorry, only just noticed this thread.
> 
> Good work on spotting this. I agree having separate plugins makes the  
> most sense.
> 
> I'm in favour of this plan with a few changes below.
> 
> On 12 Nov 2007, at 09:21, Andreas Ericsson wrote:
> 
>> I'd suggest doing this:
>> Keep check_ntp for now, but introduce check_ntp_peers (the current
>> check_ntpd).
>>
>> Introduce check_ntp_local_offset, doing what check_time_ntp does  
>> (or is
>> intended to do anyways).
>>
>> These two break nothing, so it can be done any time, really.
> 
> And:
>    - add a deprecation note in check_ntp --help with preference to  
> check_ntp_time and check_ntp_peers

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").

>    - add a similar note in NEWS

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.

>    - include the sed one liners to suggest which new plugin to use  
> based on their syntax (this is very a good idea - I wonder if we  
> could have some perl script that, if you point var/objects.cache at  
> it, it will pull out recommended changes to plugins)

That could go in the release-notes document.

>    - add a comment to http://nagiosplugins.org/plugins/check_ntp to  
> use these new plugins

I can take care of this

> So people will still have check_ntp, but we recommend and encourage  
> the use of the new plugins.
> 
> Thomas, can you merge your branch into trunk with this?

I still have some work on check_ntp_peers, some tests on both new
plugins (have you looked at the new check_ntp.t? It covers all three
plugins with many more checks, but if you prefer separate checks I can
split them up easily), and some code review...

I kind of paused development of this as I wanted some time to think
about it, and ideally get other reviews like yours... Since you seem
enthusiastic about it and want to go forward, I'll hurry up and get this
done asap.

> 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.

>> 1.5:
>> Make check_ntp_local_offset install as check_ntp_local_offset and
>> check_ntp, while adding -j and -k to check_ntp_local_offset, but
>> silently ignoring them.
>>
>> 1.6:
>> Make check_ntp_local_offset give a warning when it gets -j or -k,
>> and deprecate check_ntp (with a warning if it's called with that
>> name).
>>
>> 1.7:
>> Remove check_ntp.
> 
> I'd probably be a bit more aggressive and say in 1.5, check_ntp just  
> returns CRITICAL with "obsolete - use check_ntp_time and  
> check_ntp_peers instead" since everything is in place for a  
> conversion already, but if you all think a more conservative approach  
> is better, we can do it this way.

IMHO, UNKNOWN would be more appropriate. Afaik just removing the plugin
would return UNKNOWN as well (not arguing that we should do it though).

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).

> Let's make a decision on this - I need to get a roadmap published and  
> this can be added.

Yep, I was about to suggest that too. IMO that will help us drive our
development efforts to get further and better. You should talk with
Holger as he has some nice plans for the C plugins.

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

iD8DBQFHPIqG6dZ+Kt5BchYRAmssAKCbN979a8aiqGfMFbNOxLqKIharaQCfUuUY
xB3fS3ieoGkKg+UB6GcxDMY=
=3LjL
-----END PGP SIGNATURE-----