expirationWarningThreshold

[Brent Putman]

On 5/14/17 7:15 PM, Tom Scavo wrote:
>
>> 3) it's going to expire before the next scheduled refresh
> but how do you know that?

Each refresh operation computes the date/time for the next refresh and
schedules it.  So the resolver knows it because it decided it.

>
> Well, you just said "next scheduled refresh," but that is a configured
> event, right?

Well, it's computed, based on both resolver configuration and the
metadata's validUntil and cacheDuration.  (None of this is new, nor has
it changed in a long time).


> Yeah, I guess so, but that's a bit of a concern. It means that
> changing the validity interval on the file may breaking existing
> configurations. For example, suppose a federation has the following
> characteristics:

Well, nothing is going to "break".  This is just about logging a WARN. 
And remember that it also logs if the metadata will expire before the
next refresh, so that takes care of the case of some assumptions changing.


> For the current operation, expirationWarningThreshold might be set to
> PT7D (or more). For the future operation, PT3D makes sense.


Well, I personally think both of those are way too long.  I think
probably 24 hours is the most that makes sense - unless you really
don't want to get notified and have to do something on a weekend, in
which case maybe it's longer. (But I don't see how IT devops people can
really get away with that these days...)   But each person will have
their own requirements.  It's really more of an operational question of
how paranoid you want to be.

>
> Clearly PT7D won't work for the future operation. Should deployers be
> advised to configure PT3D for the current operation so that they don't
> have to reconfigure in the future?
>

Maybe. But if fundamental assumptions about the metadata publishing
change, then I think many of the config params (e.g. min- and
maxCacheDuration) might have to be revisited by the deployer.  We can't
deal with everything.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170514/e1e1d713/attachment.html>