Deployers have multiple metadata aggregates from which to choose. This page outlines available options. Policy considerations and general configuration issues are discussed on the Metadata Consumption page. Guidance on how to configure specific Metadata Client Software is also available.
Current Status of InCommon Metadata (March 31, 2014)
All metadata aggregates are signed with the same metadata signing key and have exactly the same content.
Production Metadata Aggregate
- signed using the SHA-256 digest algorithm
Fallback Metadata Aggregate
- signed using the SHA-1 digest algorithm (until June 30, 2014)
Preview Metadata Aggregate
- (identical to the Production Metadata Aggregate)
See the Phase 1 Implementation Plan of the Metadata Distribution Working Group for more information.
Multiple metadata aggregates allow InCommon to deploy changes to metadata more quickly, easily, and safely.
The legacy metadata aggregate was replaced by a redirect (to the Fallback Metadata Aggregate) on March 31, 2014.
The metadata server on vhost wayf.incommonfederation.org
has been phased out. Moving forward, all new metadata services will be deployed on vhost md.incommon.org
.
Metadata Aggregates
Late in 2013, InCommon Operations introduced three new metadata aggregates at the following permanent HTTP locations:
- http://md.incommon.org/InCommon/InCommon-metadata.xml (production)
- http://md.incommon.org/InCommon/InCommon-metadata-fallback.xml (fallback)
- http://md.incommon.org/InCommon/InCommon-metadata-preview.xml (preview)
Metadata consumers choose exactly one of the above aggregates depending on the immediate requirements of their deployment.
|
Availability |
Stability |
Reliability |
Affinity |
---|---|---|---|---|
preview aggregate |
24x7 |
experimental |
leading edge |
persistent |
production aggregate |
24x7 |
stable |
mainstream |
persistent |
fallback aggregate |
24x7 |
legacy |
trailing edge |
transient |
Production Metadata Aggregate
In the best possible world, a deployment would configure itself to refresh its metadata store from the production metadata aggregate and that would be the end of it. The problem is that metadata aggregates are brittle by their very nature, that is, a small change to metadata may have unexpected effects downstream. If this happens, a deployment can “fall back” to a previous version of metadata that is known to be backward compatible.
Fallback Metadata Aggregate
As suggested in the previous section, the fallback metadata aggregate comes into play when a breaking change is inadvertently introduced into InCommon metadata. When a change is made to the production metadata aggregate, and that change breaks a downstream metadata process, an affected deployment can temporarily migrate to the fallback metadata aggregate. This gives the deployment time to adjust to the breaking change.
The fallback metadata aggregate is transient in the sense that backward compatibility is provided for a limited, predetermined period of time. This forces deployments to adjust to breaking changes to production metadata albeit in a controlled environment.
Preview Metadata Aggregate
Like the fallback metadata aggregate, the preview metadata aggregate helps manage the introduction of potentially breaking changes into InCommon metadata. Before such a change is deployed in production, it is first introduced in preview mode. Any issues that surface are addressed before the change is moved to production.
The preview metadata aggregate is designed for deployments on the leading edge, such as test and dev deployments. Such deployments are strongly encouraged to consume the preview metadata aggregate instead of the production metadata aggregate.
Production or Preview?
An important decision point for each deployment is whether to consume the production metadata aggregate or the preview metadata aggregate.