expirationWarningThreshold

[Tom Scavo]

On Sat, May 13, 2017 at 11:23 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>
> On 5/13/17 8:26 PM, Tom Scavo wrote:
>>
>> What exactly is a "completed metadata refresh?" I assume that does not
>> include an attempted metadata refresh that was short-circuited via
>> HTTP Conditional GET, correct?
>
> No, it includes literally every refresh cycle.  The eval is done at the end
> of the refresh() call, regardless of what did or did not happen during the
> refresh.

Ah, thanks for clarifying that. That makes much more sense.

> The issue is: https://issues.shibboleth.net/jira/browse/OSJ-200

I see I'm a little late to the party :-)

> The main use case that prompted Scott to open the issue is precisely what
> you mentioned above:  No new metadata bytes were fetched b/c they haven't
> changed - BUT the metadata is either expired or in danger of expiring
> "soon".

Understood.

> So now at the end of the refresh we check the live batch root validUntil,
> and log a WARN on three cases:
>
> 1) metadata is already expired or otherwise invalid
> 2) it's going to expire within the configured expirationWarningThreshold

Those two cases make sense...

> 3) it's going to expire before the next scheduled refresh

but how do you know that?

>> Presumably, an appropriate setting for expirationWarningThreshold will
>> depend on the values of the other configuration parameters.
>
> I suppose that's true

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

> although I think you also need to factor in knowledge
> about the "expected" validity duration of the metadata source.

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:

Current operation:
Metadata is published on business days (excluding weekends and holidays)
Maximum 5 days between signings
validUntil is 14 days

Future operation:
Metadata is published daily (including weekends and holidays)
Maximum 1 day between signings
validUntil is 7 days

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

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?

>> Suppose a
>> reloading metadata provider is configured to refresh metadata at least
>> daily. If validUntil is 14 days in the future, then the
>> expirationWarningThreshold should be set to PT13D, right?
>
> I'm not sure about that.

Right, I incorrectly assumed that "completed metadata refresh" implied
updated metadata.

> The point of the WARN log is to have proactive
> notification of when something goes wrong.  For example, the metadata
> publisher's process stops working, or the publishing endpoint stops
> responding, etc.  So the "typical" validUntil isn't really the main concern
> here.

Yes, I get that now.

> The value really is probably "How much time in advance of a potential
> expired metadata situation do you want to see a WARN log, so you can
> intervene and do something about it?"

For my particular situation, I don't know the answer to that question.
I need to think about it some more.

Thanks,

Tom