Per-Entity Metadata Working Group

["Cantor, Scott" <>]

> > > b) periodically downloading an aggregate that contains all of
> > > the entities (since we expect aggregates to stay around for
> > > some time) and writing it to the side on disk but not using it
> > > except when detecting that MDQ queries are failing (hence not
> > > having to take up memory when not necessary).
> >
> > No, apart from discovery-motivated necessities, but not for basic use, no.
> 
> Again, to be pedantic:
> 
> Is your argument that the extra costs for the Shibboleth team
> and the complexity of such a design outweigh the perceived
> benefit of being able to load metadata for a "not-recently
> required entity" during a MDQ service outage?

Not at all; in fact, there are no costs for us, it already works today. I'm 
dismissing it on the basis that the aggregates are presumed to be headed to 
an unusable state.

Unless you mean something different by this? There's no way we could use an 
aggregate in any sort of fallback mode unless we chopped it up into bits, and 
that's really option a in the end.

As I said offline, a simple way to backstop MDQ on a server now is to build a 
job that downloads and verifies the aggregate and spits out signed entities 
into the filesystem so the disk-cache support we add would just load them. 
Could even be done just for the most critical peers in a simple MDQ-calling 
script.

But that's more option a than b to me. I was treating b as "load the 
aggregate like today as the second-choice metadata source".

-- Scott