[[PageOutline]]
= Coding Sprint, Experimenter Tutoring and Operations Hands-On =
The joint software coding sprint, experimenter tutoring session, and
operations hands-on-with-GENI session is an informal session where
aggregate and tool developers will discuss software details,
experimenters will run though GENI tutorials or ask questions of the
GPO for help running experiments, and GPO operations staff will help site ops/admins folks with anything they're interested in.
== Schedule ==
Thursday, 1:00pm - 3:30pm
== Session Leaders ==
{{{
#!html
Developers |
Experimenters |
Operations |
|
|
|
|
Sarah Edwards GPO |
Aaron Helsinger GPO |
Niky Riga GPO |
Josh Smift GPO |
}}}
If you have any questions or comments before/after the tutorial, please find one of us!
Developers: Sarah Edwards, Aaron Helsinger, GENI Project Office
Experimenters: Niky Riga, GENI Project Office
Operations: Josh Smift, GENI Project Office
== Agenda / Details ==
This software development session provides an opportunity for GENI engineers to collaborate in real time on a particular software or documentation issue. The topic will be selected well in advance of the conference, based on need and key party availability.
The GPO will also hold a tutoring session for GENI experimenters, where experimenters can come and work on various online GENI tutorials. The list of available tutorials will be advertised in advance of the GEC. The GPO will answer questions and provide assistance. Experimenters with an idea they want to work on are encouraged to come do so in the same room, so that they can have support from the on site GPO staff and other experimenters.
GPO operations staff will also be available to help GENI ops/admin
folks who'd like a hand getting set up with GENI credentials, the Omni
command-line tool, etc. This can be useful if you're running a GENI
aggregate, so you can create a slice and some slivers, and test for
yourself whether the aggregate manager is working like you expect. We'll also be happy to discuss any other topics of
interest to the ops/admin community.
== 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 [wiki:GEC17Agenda/UniformExperimenterExperience 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.