Changes between Version 9 and Version 10 of GEC17Agenda/CodingSprintTutoring

08/02/13 10:04:57 (6 years ago)
Aaron Helsinger



  • GEC17Agenda/CodingSprintTutoring

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