Re: [Nagios-users] [Nagios-devel] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated)
Original Message Subject: Re: [Nagios-users] [Nagios-devel] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated) From: Andreas Ericsson To: Nagios Users List Date: 2011-05-30 14:27 > Taken, with the exception of the cgi parts. Since the cgi's aren't > multi-threaded, they don't really need reentrant macro functions > and the change to them is just churn with no benefit. Ok - no problem at all. It was just to keep compatibility throughout the complete source but in fact you are right. > I'll take this on good faith, having tested it manually my self. It's > possible someone else can add a test-case for this in the future, > which would be a welcome change. > > Expect the patches to show up in svn in a couple of hours when I'm > on a sane link and can sync properly again. Thanks - I'll check later on. Now it's time for sun & beer ;-) -- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: michael.friedr...@univie.ac.at phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax:+43 1 4277 14338 web:http://www.univie.ac.at/zid http://www.aco.net Icinga Core& IDOUtils Developer http://www.icinga.org -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] [Nagios-devel] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated)
I've finally pulled my thumbs out of my arse and taken the time to apply these (the ones that Ton didn't beat me to, anyways). See minor comment below though. On 05/12/2011 01:13 PM, Andreas Ericsson wrote: > On 05/12/2011 09:19 AM, Michael Friedrich wrote: >> Hi Ton, >> >> Ton Voon wrote: > [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 :) > Taken, with the exception of the cgi parts. Since the cgi's aren't multi-threaded, they don't really need reentrant macro functions and the change to them is just churn with no benefit. 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. > I'll take this on good faith, having tested it manually my self. It's possible someone else can add a test-case for this in the future, which would be a welcome change. Expect the patches to show up in svn in a couple of hours when I'm on a sane link and can sync properly again. -- Andreas Ericsson andreas.erics...@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. -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] [Nagios-devel] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated)
On 05/12/2011 04:52 PM, Julien Mathis wrote: > >> 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. >> >> > Yes we will work on the subject. We hope you will benefit these > developments. Glad to hear it :) Which version (svn revision number or git commit id) did you fork from? I'm trying to see what you've done so far, but with patches recently being applied in Nagios core as well, it's hard to make out the diff properly. If you're using an import of the code for your repositories it might be easiest just to publish those online, if possible. > We have repeatedly offered our help, without success... > That must be something I've missed. I know some patches have fallen between the cracks last year and some this spring when I was busy at $dayjob with various things, but the amount of patches submitted and that I've been poked for isn't such a vast amount that I'd think it worth announcing a new fullblown fork of Nagios for. Ah well. I know that not all patches that are submitted are accepted into the core. That's normal. If I *had* accepted all patches submitted in the 2 or more years that I've been reviewing and queueing patches for Nagios, few of the addons that exist today would still work without major surgery, and Nagios would have been bloated beyond belief. Some patches get accepted immediately. Some get deferred until the next major release because they break the API's that broker modules rely on. Some patches get accepted after a couple of rounds of review and polish, and some patches get dropped on the floor because they add something that is highly complex and useful only to some very few people, or they solve a problem for which there is a very easy different way to solve the same thing that doesn't involve adding complexity to the core. Some also have been dropped because they were downright crap. I tend to not remember who was responsible for a particular patch, but if the content of the patch is mentioned I will usually remember what I thought of it. Very engineerish, imo. > >>> 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. >> > > That's not the goal. We want to keep the compatibility. > > We do not want war. We do not want to split between all projects "Nagios (R) > ". > We just want to bring new thinking and help the project without breaking > your > organization. We hope you understand us. > Sure do. So let's work together. Me, Ton and Ethan just had a meeting about an hour ago where we decided on some features that we want to implement in Nagios that, according to ideas.nagios.org and the Nagios bugtracker at tracker.nagios.org matches quite closely what the users want. I'll be sending out an email tomorrow afternoon, crossposting to nagios-users and nagios-devel (actually, it'll be several emails), requesting help in certain areas that we've decided to improve on in the very near future. I've also committed to make these changes my self, though I'd prefer to share the work with the rest of the community. Matthieu Kermagoret, among others, would be a valuable asset in that, as he's proven more than once that he's not only a competent coder but also very pleasant to work with. Feel free to pick up one of the tasks we've decided to do from those emails, either for Centreon Engine (from where we can backport it to Nagios if it plans out the way I expect it will), or as patches to Nagios. Or perhaps both. Either way works for me. -- Andreas Ericsson andreas.erics...@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 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.n
Re: [Nagios-users] [Nagios-devel] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated)
Hi, Andreas Ericsson wrote: > Good idea. Involving the community to help test things is something > I've been wanting and trying to do for a long time. the mailinglists are not optimal. try a dev blog, ask on fb/twitter, and maybe cleanup the bug tracker a bit. using new social media in a good way can make life easier. but i think i already mentioned that a while ago to tony on irc. > 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 :) thought so, and the recent change to svn would have made the diff changed, idea - grab some beers (i'm sure you will on the nagios conference in italy) and do it together with ton and ethan, showing some git ;-)) > 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. Point is, in that special change on previous release, no test was provided either. So by just reverting the diff, it could have resolved the issue either way. But I also understand Ton's demanding though I don't have time writing those tests myself. For me, it's working, and the other part of the cake can be done by someone else amongst fellow nagios users/contributors. > 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. Even if it is, I like their recent patches and overall contributed work to Nagios. If there are politics those guys should do that on closed doors, and not disturb the way development flows. i did not like that on the netways stuff, on the shinken trademark thingies, and if that now pops up - well, as said, putting it into the right channels, but not nagios-devel imho. > 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. Most possible. I'm keen on sharing some of my not-currently-available ressources thinking with them about future changes and/or improvements. > 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. There comes the day in history where an ABI must be broken in order to allow the implementation of things you need. Although remaining compatible, this is not a good solution, I totally agree on that. Either way, Shinken did it right, introducing new things, independent of the down below code. Let's see what future might bring on that. Communication seems to rather broken in various ways, so let the code and releases talk instead, sharing ideas and man power. Kind regards, Michael -- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: michael.friedr...@univie.ac.at phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax:+43 1 4277 14338 web:http://www.univie.ac.at/zid http://www.aco.net Icinga Core& IDOUtils Developer http://www.icinga.org -- 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 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] [Nagios-devel] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated)
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
Re: [Nagios-users] [Nagios-devel] nagios patches 3 old, 1 new (fix flexible downtime on service hard state change doesn't get triggered/activated)
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. >> [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. >> = >> >> 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. > >> 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. 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). Shinken is already proofing what's possible, let's welcome another competitor in the game :) Kind regards, Michael -- DI (FH) Michael Friedrich Vienna University Computer Center Universitaetsstrasse 7 A-1010 Vienna, Austria email: michael.friedr...@univie.ac.at phone: +43 1 4277 14359 mobile: +43 664 60277 14359 fax:+43 1 4277 14338 web:http://www.univie.ac.at/zid http://www.aco.net Icinga Core& IDOUtils Developer http://www.icinga.org -- 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 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
