[[PageOutline]]

= 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
[wiki:GEC15Agenda/CodingSprint Coding Sprint] session.

== Schedule ==

Tuesday, 1pm - 2:30pm

== Session Leader ==

Aaron Helsinger, GENI Project Office

== Agenda ==

 * Stitching -- Tom Lehman, MAX ([attachment:TomL-stitching-overview-gec15-lehman-v3.pptx slides])
  * Progress Report
  * Implementation Plan
  * Design of Stitching Services
  * Stitching Schema v2
  * Questions?
 * AM API
  * Version 3 Status - Aaron Helsinger ([attachment:AMTopics-GEC15-AHelsinger.pdf 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 ([attachment:RobR-UpdateProposal.pptx slides])
 * 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 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 ==
 * [wiki:GeniNetworkStitching Network Stitching design status]
 * [wiki:GAPI_AM_API_V3 AM APIv3 Specification] 
 * [wiki:GAPI_AM_API_DRAFT AM API draft proposals]
 * [http://www.geni.net/resources/rspec/ext/shared-vlan/1/ Shared VLAN RSpec extension]
 * [wiki:GAPI_AM_API_DRAFT#ChangeSetC:Update Revised Update() proposal]
 * [http://lists.geni.net/pipermail/dev/2012-July/000823.html Jon Duerig's Update proposal from July]