expirationWarningThreshold

[Brent Putman]

On 5/16/17 6:31 PM, Michael A Grady wrote:

>
> I'm not sure why you think setting this value to more than 24 hours
> wouldn't make sense.

That number was mostly driven by  1) the notion that trying to reduce
false alarms is good 2) an assumption that if you notice a problem, the
metadata source can fix quickly after being notified (less than a day).
If either of those isn't true, then maybe > 24 hours does make sense. 


> Take the InCommon metadata, for example. I know it has a valid period
> of 2 weeks, and I know that just about every business day that
> metadata changes, and should be (if I have recommended refresh
> settings) therefore refreshed about once a business day. So if see
> that the validUntil of my copy is less than a week, then something is
> going wrong. it doesn't take getting to within 24 hours or less of it
> expiring to know I have a problem and things aren't working as I'd expect.

Sure.  If you want that much notice, then you can set to 7 days or
whatever.  But there could be legitimate reasons why the "expected"
update schedule changes for some period of time (i.e. no updates to
publish), and then corrects itself well within days of expiration.  You
would get a false alarm in that case with a lengthy threshold.  If
you're ok with that, then that's fine.

As I said somewhere in this thread, it really comes down to how paranoid
you want to be.  More paranoid = greater chance of false alarm.  And if
you have a 7 day threshold and the warning fires, you have to decide
whether you go and pester the metadata source immediately, or wait a few
days to see if it resolves on its own.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170516/0c21d817/attachment.html>