MDQ
Donald Lohr
lohrda at jmu.edu
Wed Feb 3 18:17:11 UTC 2021
I realize it is splitting hairs.
InCommon's "Migrating to the MDQ Service"
(https://spaces.at.internet2.edu/display/MDQ/migrate-to-mdq) speaks to:
1) retiring the legacy metadata service at *md.incommon.org*
2) changing to consuming metadata from *mdq.incommon.org*
3) the legacy metadata service is approaching the 100MB mark when
aggregated & is no longer sustainable for the vast majority of deployments
4) InCommon will continue to provide aggregates at the new metadata
location, signed with the new key, for the foreseeable future (at least
the next five years), barring an unforeseen event that forces us to
retire aggregates.
So my read on this is, moving from the *md* url to the new *mdq* url is
all that is needed to move to the new mdq service, no matter how you
configure it. The new *mdq* service supports (as document by InCommon):
a) caching the entries as needed by using DynamicHTTPMetadataProvider
b) caching entries as needed by using DynamicHTTPMetadataProvider +
pre-fetching metadata for specific SPs by using
FileBackedHTTPMetadataProvider
c) caching the entire aggregate by using FileBackedHTTPMetadataProvider
as supported via the md service
Switching to the new mdq service is changing the url. Configuring for
the new mdq for any of its features (based on the needs of the
organization - with one of the above a-c options) is the second part.
While the two can be done together, they should not be married together
to exclusively mean or not mean switching to or not switching to the new
MDQ service.
While the a benefit to the new mdq service is grabbing only the metadata
(just-in-time) needed by the organization, meaning less cached metadata.
The one negative would be if the mdq site is down and metadata can not
be obtained when using DynamicHTTPMetadataProvider for per-entity or the
full aggregate. The advantage on using FileBackedHTTPMetadataProvider is
having the local copy.
I'm not saying the uptime of InCommon mdq service is poor, I'm just
trying to have the best of all options available from a configuration
using the mdq service.
Don
On 2/3/21 12:32 PM, Les LaCroix via users wrote:
> *CAUTION: *This email originated from outside of JMU. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
> ------------------------------------------------------------------------
> Donald,
>
> ...the thinking is to initially configure MDQ for "All Entities"
>
>
> IIUC you're reading the "Retrieving metadata as aggregates" section,
> which lists URLs that can be used with
> the FileBackedHTTPMetadataProvider in lieu of the old URLs. If you
> replace the URL in your legacy configuration, I believe that all you
> are doing is creating an equivalent file using a new source URL. In
> my mind, that's not really "configuring MDQ". Configuring MDQ would
> be defining a DynamicHTTPMetadataProvider to use the InCommon MDQ
> service, along with removing (or commenting out) the
> old FileBackedHTTPMetadataProvider stanza for the old way of acquiring
> metadata from InCommon.
>
> -Les
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.carleton.edu_&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=mPdTXa0OrmpjuXLqvY1x2XImtYgjZp_Nh1X_ZJESw2A&e=>
>
>
>
> *Les LaCroix '79*
>
> Strategic Technologist
>
> Information Technology Services
>
> t: (507) 222-5455
>
>
>
> On Wed, Feb 3, 2021 at 11:03 AM Donald Lohr <lohrda at jmu.edu
> <mailto:lohrda at jmu.edu>> wrote:
>
> 1)
> https://spaces.at.internet2.edu/display/federation/Download+InCommon+metadata
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__spaces.at.internet2.edu_display_federation_Download-2BInCommon-2Bmetadata&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=XWPY5gzkRmSP9VR8xuUf6klXpmYZbRb0DV_K-5FuA0g&e=>
>
> and
> https://spaces.at.internet2.edu/display/MDQ/production-metadata
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__spaces.at.internet2.edu_display_MDQ_production-2Dmetadata&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=ToxeSKZ5ufyu25ESZCQJd35MqVRWrKT83mP_O63iUJA&e=>
>
> ...speaks to their MDQ "akin to legacy" offering which gets the
> entire
> file.
>
> 2) I believe I just answered my original question. In all their MDQ
> examples DynamicHTTPMetadataProvider is used. In our current MD
> (legacy)
> configuration FileBackedHTTPMetadataProvider is used.
>
> Thanks,
> Don
>
> On 2/3/21 11:44 AM, Cantor, Scott wrote:
> > CAUTION: This email originated from outside of JMU. Do not click
> links or open attachments unless you recognize the sender and know
> the content is safe.
> > ________________________________
> >
> >> In the new MDQ configuration to support this "akin to
> legacy" approach, does it support writing to a file similar to the
> >> old MD service like:
> > No. Doing that is something you would do with the older batch
> metadata provider by pointing it at that URL. I would not think
> InCommon would want that unless they intend people to move off the
> old URL for some reason but continue to suck down the whole file.
> That's not my impression.
> >
> > -- Scott
> >
> >
> > --
> > For Consortium Member technical support, see
> https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=kyaNL4qLve7vrv2fAj0zytujAQ87UhscZGPXxDyV9Z0&s=yf5zydTHnILqRhBXTutaKqSbAQDgIh7V7E0XtWJVabA&e=
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=kyaNL4qLve7vrv2fAj0zytujAQ87UhscZGPXxDyV9Z0&s=yf5zydTHnILqRhBXTutaKqSbAQDgIh7V7E0XtWJVabA&e=>
> > To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> <mailto:users-unsubscribe at shibboleth.net>
>
> --
> D o n a l d L o h r
> I n f o r m a t i o n S y s t e m s
> J a m e s M a d i s o n U n i v e r s i t y
> 5 4 0 . 5 6 8 . 3 7 3 0
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwMFaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=YuDkHVbNM9swmUy8F09P-iTUoavftOtQrZe4sv7jJ98&s=EQ254IY8Tz5fJSwq9vJKTw3qT5Y9eyibfV3okxLOIDg&e=>
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
> <mailto:users-unsubscribe at shibboleth.net>
>
>
--
D o n a l d L o h r
I n f o r m a t i o n S y s t e m s
J a m e s M a d i s o n U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20210203/c289c887/attachment.htm>
More information about the users
mailing list