Per-Entity Metadata Working Group - 2016-08-24
Agenda and Notes
[Etherpad used to create these notes: Agenda_and_Notes_-_2016-08-24.etherpad]
Dial in from a Phone:
Dial one of the following numbers:
Meeting URL (for VOIP and video): https://bluejeans.com/195646158
Wiki space: https://spaces.at.internet2.edu/x/T4PmBQ
- Scott Koranda (LIGO)
- Nick Roy (InCommon/Internet2)
- David Walker (InCommon/Internet2)
- IJ Kim (Internet2)
- Scott Cantor (tOSU)
- Michael Domingues (University of Iowa)
- Tom Scavo, InCommon/Internet2
- Tom Mitchell (GENI)
- Ian Young
- John Kazmerzak, University of Iowa
- Kevin Morooney (InCommon/Internet2)
- Walter Hoehn (Memphis)
- Jorj Bauer (Temple)
Agenda and Notes
- NOTE WELL: All Internet2 Activities are governed by the Internet2 Intellectual Property Framework. - http://www.internet2.edu/policies/intellectual-property-framework/
- NOTE WELL: The call is being recorded.
- Agenda bash
- FYI: InCommon TAC webinar at 2:00p ET today
- Slides: https://docs.google.com/presentation/d/1YJiDpFUshWKpP77iBw1qvQeREHsRgVL8vTsvt3JEhfA/edit?usp=sharing
- Distributing split aggregates
- Is this a good idea? How does it fit in our roadmap?
- (SK input) Yes, good idea, should be in roadmap in near future
- (DHW) Does the end of our roadmap include aggregates?
- (SK input) No
- Nick: We'd (InCommon Ops) like to avoid doing this, unless it's necessary.
- Tom has a document outlining the issues. He'll put a version on our wiki space.
- TomS: Middleground is to create an IdP aggregate and hold it in reserve.
- Things are more critical for SPs. IdPs are in better shape.
- Things are harder, however, for SPs that use the aggregate for discovery.
- Perhaps create a JSON file for discovery
- IJ has run some experiments that have given Ops confidence that they have the capacity to do signing for multiple MDQ services
- Tom is hoping to have something to show at TechEx.
- ScottC said that there may be a fix coming soon for 32-bit IdPs (which is where the biggest concern has been)
- So, the larger concern may shift to IdPs.
- An IdP-only aggregate may still make sense. It can be used to support discovery, and it's much smaller. (There are fewer IdPs.)
- It's not clear there are any good alternatives to a list of IdPs for discovery.
- => We agree we should have an IdP-only aggregate, to preserve stability for the federation while the infrastructure evolves.
- Should it have the three stages (preview, production, fallback)? Current working thought is to only pull off of the production aggregate.
- It should stay around as long as we provide any aggregates.
- Should production of split aggregates have the same stages as current aggregate?
- Many of the risks are still there. Who needs to accept those risks?
- An IdP-only aggregate is no more risky than the current main production aggregate (since both incorporate eduGAIN metadata directly, without curation). In fact, an IdP-only aggregate is less risky since it is significantly smaller.
- (DHW) Somewhat related question: Should MDQ services have stages?
- If you change all entities' metadata for some reason, it has the potential to break all MDQ-distributed entities.
- Global mods could be rolled out slowly over time, a few entities at a time.
- For later discussion... How do we handle preview/fallback for new versions of the MDQ server software and protocol?
- Draft report
- Constructing the text/language for availability requirement
- Azure SLA example: https://azure.microsoft.com/en-us/support/legal/sla/cdn/v1_0/
- Amazon CloudFront example: https://aws.amazon.com/cloudfront/sla/
- Google Cloud CDN example: https://cloud.google.com/cdn/sla
- There was general consensus on the structure of the Availability section. We'll need to talk more about the implications of the specific 3-nines metric.