| 39 | | {{{ |
| 40 | | #!comment |
| 41 | | == Session Summary == |
| 42 | | }}} |
| | 39 | == Summary == |
| | 40 | |
| | 41 | At the Aggregate Topics session, we covered a few topics for developers of aggregates and tools that reserve resources at aggregates. |
| | 42 | First we talked about how to add the ability to stitch resources together with a custom layer 2 network - stitching. |
| | 43 | 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. |
| | 44 | |
| | 45 | Aaron Helsinger then briefly reviewed progress in implementing the Aggregate Manager API version 3 and some minor changes that we have proposed. |
| | 46 | |
| | 47 | 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: |
| | 48 | - Disallow `PerformOperationalAction` for any sliver in the `geni_updating` state |
| | 49 | - Nick Bastin suggested a flag so he can allow experimenters to only `Delete` 1 sliver, but not allow other operations on a single sliver |
| | 50 | - 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 |
| | 51 | - 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. |
