[Nagios-users] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated)

[Andreas Ericsson]

On 05/12/2011 09:19 AM, Michael Friedrich wrote:
> Hi Ton,
> 
> Ton Voon wrote:
>>> 0001-fix-race-condition-on-flexible-downtime-commands-whe.patch
>> I'm going to push this one back to you to create a suitable test case. Use t-tap/test_commands.c and check return code is ERROR.
>>
>> I'd vary the inputs too to include 0 or blank or nothing
> 
> Ok. Will do when I get more time for writing more tests. Putting
> nagios-users on CC in order to allow users experiencing the same
> problems to test this patch.
> 

Good idea. Involving the community to help test things is something
I've been wanting and trying to do for a long time.

>>> [PATCH] move thread safe macro function prototypes with suffix _r and restore old compatible prototypes again
>>>
>>> =>    verified against latest t-tap tests, updated .gitignore
>>> 0003-move-thread-safe-macro-function-prototypes-with-suff.patch
>> I don't know enough around this area, but I know Andreas is keen on re-entrant functions, so I'll defer to him.
> 
> Possibly, maybe it also needs some further adaptions. It's not business
> critical, just compatibility critical for addon developers.
> 

I'm fairly sure I applied that one, but perhaps I was lacking the
proper amount of alcohol in my bloodstream and forgot to do the
git -> cvs export step. The patch is good and will be applied though,
since it would otherwise force us to bump the major version of Nagios
for the next release. Thanks :)

>>> =====
>>>
>>> NEW
>>>
>>> fix flexible downtime on service hard state change doesn't get triggered/activated
>>>
>>> recently, there was a change on flexible downtime triggering,
>>> allowing soft state changes to active a flexible downtime.
>>>
>>> this change removed the condition on hard_state_change check,
>>> so it only triggered those from soft state changes but not
>>> the well known older behavior.
>>>
>>> the tricky part is, that those 2 vars are not the same on each
>>> state change, so the replacement fix needs a sanitized "near-by"
>>> addin, which this patch introduces.
>>>
>>> this bug has been evaluated and debugged in deep, the fix
>>> now runs>2 months on productive systems, allowing us to
>>> trigger flexible downtimes on hard state changes too, next
>>> to the soft state changes being detected.
>>>
>>> please check https://dev.icinga.org/issues/1228 for a deeper
>>> analysis on this.
>>>
>>>
>>> 0004-fix-flexible-downtime-on-service-hard-state-change-d.patch
>> This one requires a test case too, due to its complexity. See t-tap/test_checks.c which has tests in the handle_async_check_results routine.
> 
> Ok, thanks for the hint. In case there are any users in the Nagios world
> happen to have the same problem, I'd love to see some reports after
> having that patch applied against 3.2.3 or similarities.
> 

Likewise. User-testing is very nearly as good as automated tests. At
least for accepting the patch in the first place. Many thanks.

>>
>>> please consider them for future releases as it will ease the porting-patches-from-icinga-core procedure.
>> To be honest, that's not my problem. You can make an argument that it is better for Nagios users, but an argument to make your life easier for future patches is not going to sway me. If you choose to fork, then you're accepting a certain cost of maintenance.
> 
> Of course not your problem, not even Nagios devs ones, just Nagios users
> maybe.
> 
> I was only taking the advantage to "give something back from Icinga".
> Take it or leave it. Just saying that if you're interested in further
> contributions, I'd expect some feedback (just like you did, so thanks
> for the reaction).
> If you're insisting on further automated test cases, it's fine, but will
> cause those patches to last longer on that list until resolving more
> important issues. Like I mentioned recently, there are some bugs
> affecting both, Icinga and Nagios I am currently working on.
> 

Well, some patches are obviously correct and can be applied without
adding tests for them. Where current behaviour changes, or new features
are added in already complex areas is a different matter though, but
getting the code queued somewhere might make it easier to accept from
users testing them.

> Talking of forks - I really appreciate the Centreon engine fork. Must
> have happened for a reason, remember the execvp patch on this list? I'm
> keen on seeing what they have been doing, and watching out for further
> ideas on their interesting ideas. the initial released code has various
> things already applied
> (http://www.centreon.com/Centreon/centreon-engine-download.html).

The sad part is that centreon forked three days after Nagios Enterprises
cancelled the partnership contract with Merethis (the company behind
centreon). To me, that smells a bit political.

Thanks for the link though. I've been looking for it but was unable to
find the download before you posted it. It should be interesting to see
if they can solve the I/O load problems like someone here at the
Bolzano conference mentioned they're working on. That's one of my goals
too, but so far I haven't had time to sit down and think it through
properly. If they have, we should be able to profit from their work
quite easily.

> Shinken is already proofing what's possible, let's welcome another
> competitor in the game :)
> 

Yes. And no. Shinken is incompatible with all of Nagios' current
broker modules. Icinga have broken the ABI compatibility, but not to
the same extent. Shinken has some very neat ideas (and some not so
neat ones too). Like all good engineers, I'll happily borrow the
good ones and let the bad ones go hang.

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

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay