Skip to Content.
Sympa Menu

metadata-support - [Metadata-Support] Best practice to test new metadata

Subject: InCommon metadata support

List archive

[Metadata-Support] Best practice to test new metadata


Chronological Thread 
  • From: <>
  • To:
  • Subject: [Metadata-Support] Best practice to test new metadata
  • Date: Fri, 14 Feb 2014 12:05:48 -0500 (EST)

I am clearly very confused about the intended purpose of the 'preview'
metadata aggregate. Rather than get into that now, though, I would like to
find out what the best practice is to test changes to production metadata.

We have an entityID=https://dmp.cdlib.org. I plan to make extensive changes to
that metadata to 1) support a number of new DNS names and SSO endpoints that
will be used to migrate from version 1 to version 2 of the DMPTool
application, and 2) support our request to become part of the InCommon
Research and Scholarship category.

I have already made similar changes and tested by editing the production
metadata for our development and staging environments - entityIDs
https://dmp-dev.cdlib.org and https://dmp-stage.cdlib.org. However, I would
like to be able to test, and quickly roll back, the changes to our production
metadata somewhere other than the actual production environment.

My initial thought was that I would put the new metadata into the preview
aggregate, modify my SP to use the preview metadata provider, and see if I
could still log in. But this is clearly not the best way to proceed because
it's not what the preview aggregate is intended to do, and I'm not sure if the
IDPs would even see the new metadata.

What is the recommended approach to testing, and quickly rolling back, changes
to production metadata? Where should I install the modified SP metadata? How
do I get at least one IDP to read that modified metadata and confirm that
everything works as expected? Is this a job for testshib?

--Ken Weiss



Archive powered by MHonArc 2.6.16.

Top of Page