|
From: J.C. C. <cl...@te...> - 2015-04-24 16:29:49
|
On Fri, April 24, 2015 8:36 am, J.C. Cleaver wrote: > On Thu, April 23, 2015 12:23 pm, Andy Smith wrote: >> This didnt work for me, the purple is not set by an incoming message >> but rather in check_purple_status() I think. >> -- >> >> Andy > > > Indeed. The code seems to have changed somewhat since this patch was > originally written. > > Can you try this? > That one will catch ones that are flipping into purple during a downtime period, but not ones that are already purple by the time the downtime period starts. I wouldn't want to force purples to be rescanned every minute across the board, so setting a low interval on only for hosts that have a downtime configured seems like a middle ground (although it effectively becomes that if you've set DOWNTIME on the .default. host). At first I thought that pre-calculating the validity on purples for those hosts to the next scheduled downtime start might be worth the trade-off, but we'll run into the same problem if the downtime is changed between now and then. We'll also have a problem when downtime is added in on a host that didn't have it before. Seems like we need a better signal of clearing of certain metadata when a specific host entry is updated, but that's a bit of a bigger project. For now, this (revised) patch should get the scanning working, with the exception of those edge cases. -jc |