Changes between Version 9 and Version 10 of GEC17Agenda/CodingSprintTutoring

Timestamp:

08/02/13 10:04:57 (11 years ago)

Author:

Aaron Helsinger

Comment:

--

GEC17Agenda/CodingSprintTutoring

@@ -60 +60 @@
 interest to the ops/admin community.
 
-{{{
-#!comment
-=== Detailed Developer Topics ===
- - Update: questions, concerns, limited implementations
- - Stitching
-  - Questions?
-  - Concerns?
-  - Future
-   - VLANs are limited - tunneling?
- - Uniform Experimenter Experience
-  - API for getting slice/sliver and other information from inside a node
-  - Other
- - Speaks For
- - Common CH API
- - OpenID issues
- - Other topics
-}}}
+== Session Summary ==
+
+At the joint Coding Sprint, Experimenter Tutoring and Operations
+Hands-On session, each of the three groups had productive discussions.
+
+There were several experimenters who came to the session for one on
+one help running exercises from the tutorials. Operators worked out
+some issues with reporting monitoring data. And developers worked through a
+handful of issues to provide added functionality for experimenters.
+
+Overall, developers agreed to:
+ - Collect ports used by GENI services, for use in testing networks for tutorials
+ - Implement a `geni-get-info` script for each compute aggregate and substrate to provide slice and aggregate information within a node
+ - Negotiate a new AM API v3 operational action for changing SSH keys installed on an existing node
+ - Some conventions for tools to work with the ExoSM, an aggregate of aggregates
+
+=== Developer Coding Sprint Session Details ===
+
+Niky raised the issue of running tutorials on new networks, where
+ports may be blocked. InstaGENI and ExoGENI agreed to provide lists of
+the ports their services use.
+
+Following on from the Uniform Experimenter Experience session, we
+discussed what information experimenters would like to have available
+from within a reserved compute resource. Starting with wish lists from
+GENI Desktop, the data currently available at InstaGENI and ExoGENI,
+and other voices in the room, we compiled a consolidated wish
+list of information, including the local `client_id`, the
+aggregate URN, the slice manifest, and user accounts and SSH keys. We
+discussed how to get this data, and noted that the actual mechanism
+would depend on the aggregate and substrate (VM vs bare metal). To hide this, we agreed to provide a
+common script that could be available at all aggregates, whose
+implementation would hide the aggregate specific differences. We
+agreed to work out the implementation details in coming weeks.
+
+Following on from the Developer sessions, we discussed how to provide
+`Update()`-like functionality, before a full `Update()` is
+implemented. We agreed that aggregates could update the installed SSH
+keys using a new operational action with
+`PerformOperationalAction()`. The GPO agreed to propose something, and
+has since posted a proposal on
+[wiki:GAPI_AM_API_DRAFT#ChangeSetQ:Supportchangingusersandkeysonexistingcomputeslivers the AM API Draft wiki page]. Rob Ricci suggested that with some
+changes, InstaGENI experimenters could make an aggregate-local LAN
+shared, and then connect new nodes to this shared LAN. InstaGENI will
+work to add this capability.
+
+We then discussed how to support the ExoGENI ExoSM in tools. The ExoSM
+is an aggregate of multiple component managers, and this breaks some
+assumptions in existing tools. After some discussion, the solution
+appears to be that the sliver_id in manifest RSpecs will reflect the
+aggregate that issued the reservation, while the component_id and
+component_manager_id will reflect the component manager (i.e. the
+specific ExoGENI rack). Note that tools will require some extra
+workflow to identify the aggregate where the experimenter wants a
+reservation, and to deal with unbound requests.
+