Version 13 (modified by Aaron Helsinger, 9 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.


Tuesday, 1pm - 2:30pm

Session Leader

Aaron Helsinger, GENI Project Office


  • Stitching -- Tom Lehman, MAX (slides)
    • Progress Report
    • Implementation Plan
    • Design of Stitching Services
    • Stitching Schema v2
    • Questions?
  • AM API
    • Version 3 Status - Aaron Helsinger (slides)
    • AM API Tweaks
      • Change Set N: Additional GetVersion fields
      • Change Set O: Refine Character Restrictions
      • Shared VLANs
      • Discussion
    • AM API: Change Set C:Update() -- Rob Ricci for Jon Duerig, ProtoGENI / InstaGENI (slides)
  • Discussion


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 the geni_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 a geni_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)