On Tuesday 09 October 2001 02:52 pm, Jim Trocki wrote:
> On Tue, 9 Oct 2001, Andrew Ryan wrote:
> > But I would like such a configurable keyword, because upalerts are
> > useful and it's nice to know if something comes back on its own and you
> > don't have to worry about it anymore, even if it is outside the period of
> > time you would care about the service going out.
> >
> > If it was coded up, would you accept the patch?
>
> sure, if it's not a horrible hack. i would imagine some simple new flag
> such as this:
I was thinking of an approach that allowed the 'catch_all_upalerts' keyword
to be placed in the same period definition, avoiding the need to define a
special _ANYTIME_ period just to catch the upalerts. There's nothing wrong
with that, I just think that this way is closer to how users would expect it
to work and reduces in fewer config file lines. Anything that minimizes
config file lines (esp in larger configs) is a good thing IMHO. e.g.,
period _DAYTIME_
alert mail.alert mis
comp_alerts
catch_all_upalerts
upalert mail.alert mis
Then modify the pach to be:
#
# check each time period for pending alerts
#
foreach my $periodlabel (keys %{$sref->{"periods"}})
{
my $pref = \%{$sref->{"periods"}->{$periodlabel}};
#
# only send downalerts that are in the proper period,
# but send upalerts anytime if catch_all_upalerts was
# selected
#
if (!inPeriod ($tmnow, $pref->{"period"})) {
next unless ( ($flags & $FL_UPALERT) &&
($pref->{"catch_all_upalerts"}) );
}
> and add this to read_cf:
I would add the same thing. I spent about 15 minutes thinking about this, so
we have a combined 18 minutes of effort :)
