Per-Entity Metadata Working Group

[Scott Koranda <>]

> > > > 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".

Understood.

Thanks,

Scott K