Version 13 (modified by 12 years ago) (diff) | ,
---|
Aggregate Manager Topics
At this developers session, we will discuss several issues relating to developing GENI aggregates and standardizing aggregate behavior. In particular, we will discuss implementing inter-aggregate VLAN stitching, issues encountered while implementing AM API v3, and adding Update() to the AM API (as discussed at the GEC14 coding sprint). This session will begin conversations that will be continued at the Coding Sprint session.
Schedule
Tuesday, 1pm - 2:30pm
Session Leader
Aaron Helsinger, GENI Project Office
Agenda
- Stitching -- Tom Lehman, MAX (slides)
- Progress Report
- Implementation Plan
- Design of Stitching Services
- Stitching Schema v2
- Questions?
- AM API
- Discussion
Summary
At the Aggregate Topics session, we covered a few topics for developers of aggregates and tools that reserve resources at aggregates. First we talked about how to add the ability to stitch resources together with a custom layer 2 network - stitching. Tom Lehman reviewed the stitching architecture, and outlined plans for implementing a topology service and a computation service. He also talked about plans for aggregates at regionals and backbones. This led to a discussion about an aggregate for ION at Internet2, allowing experimenters to reserve circuits across the ION backbone. One concern raised is that GENI may end up driving a lot of users to ION, using more bandwidth and circuits than regionals and campuses are expecting. This is a topic we will continue to discuss.
Aaron Helsinger then briefly reviewed progress in implementing the Aggregate Manager API version 3 and some minor changes that we have proposed.
Rob Ricci then discussed a new proposed method for the Aggregate Manager API: Update()
. This would allow an experimenter to modify part of their topology at an aggregate, without losing the rest of their resources. The people in the room suggested a few changes to the proposal, but were in favor of the direction of the proposal. Suggested changes include:
- Disallow
PerformOperationalAction
for any sliver in thegeni_updating
state - Nick Bastin suggested a flag so he can allow experimenters to only
Delete
1 sliver, but not allow other operations on a single sliver - Nick also expressed a concern that experimenters or their tools might delete slivers by mistake. He proposed that we modify the return from
Update()
to include ageni_next_allocation_state
for positive confirmation of slivers being deleted - Ilia Baldine suggested a manifest RSpec extension that includes a journal - a history of changes to the slice and how the current configuration was developed. The room seemed to agree, suggesting a flag to allow the manifest RSpec to only optionally include this information.
Background Reading
Attachments (3)
- AMTopics-GEC15-AHelsinger.pdf (264.9 KB) - added by 12 years ago.
- TomL-stitching-overview-gec15-lehman-v3.pptx (2.8 MB) - added by 12 years ago.
- RobR-UpdateProposal.pptx (80.4 KB) - added by 12 years ago.