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:30pm - 5:30pm

Session Leaders

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 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 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.