InCommon metadata support

[Tom Scavo <>]

On Fri, Feb 14, 2014 at 12:05 PM,  
<>
 wrote:
> 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.

Just to add a little bit to what Scott said, let me say a few words
about the preview metadata aggregate. Of the three entityIDs you
listed above, the first one should point to the production aggregate
while the latter two should probably consume the preview aggregate.
One of them, at least, should consume the preview aggregate.

When we roll out major changes to InCommon metadata, we will first
deploy them to the preview aggregate before we move them to
production. For example, we have plans to introduce a new schema, the
MDRPI schema, and some new metadata elements that depend on that
schema. These will be deployed to the preview aggregate first. After
some reasonable amount of baking time, we will move those changes to
production. In this way, problems associated with this new schema will
be minimized. See this wiki page for more information about the three
metadata aggregates: https://spaces.internet2.edu/x/SoG8Ag

Hope this helps,

Tom