Version 4 (modified by Aaron Helsinger, 7 years ago) (diff)


GEC23 Developer Roundtable

This is an informal session for GENI developers to discuss details of software integration, and software issues that affect multiple control frameworks or tools. Note that this session is separate from the parallel experimenter and operations drop-in session.


Thursday, 9.00am - 10.30am & 11.00am - 12.30pm

Session Leaders

Tom Mitchell
Aaron Helsinger

Agenda / Details

This software development session provides an opportunity for GENI developers to collaborate informally. At this GEC, the Developer Roundtable will cover two primary topics; (1) tasks and communication modes for maintaining GENI, and (2) GENI enhancements to adopt and develop now.

We will first discuss how the developer community will operate in the near future as GENI changes into operations and maintenance mode, and GECs become less frequent. What mailing lists, issue tracking, or meetings will we use? What tasks must we perform to make GENI software maintainable and transitionable? Should we follow a more formal decision process?

We will then discuss tying up loose ends in GENI development, and addressing low hanging fruit that are potential big wins for experimenters or for making GENI more maintainable and transitionable. The people in the room will decide what topics these are, but topics may include:

  • Status updates on recent development
  • Speaks For roll-out
  • Stitching (multi-point in the core, OpenFlow stitched VLANs, schema enhancements for clarity, etc)
  • AM API deployment status and draft proposals
  • Adding new resource types to GENI

Session Summary

About 30 people attended the developers roundtable. Participants included Jim Griffioen, Sarah Edwards, Michael Zink, Anirban Mandal, Tom Lehman, Rob Ricci, Xi Yang, Nick Bastin, Marshall Brinn, Tom Mitchell, Jim Chen, Hussam Nasir, Tim Upthegrove, Deniz Gurkan, Mark Berman, Chip Elliot, Niky Riga, and Gary Wong.

Topics discussed and accepted action items included:

  • Exposing aggregate availability (up? free? reliable?) to experimenters and tools, so experimenters can intelligently pick an aggregate for a reservation
    • Possible sources of data include the jFed probing tool and GENI Monitoring
    • Rob Ricci proposed that data be made available through services with common APIs.
    • Those interested in helping should use the geni-developers Google group to indicate interest and to share ideas.
    • GENI Monitoring currently requires a separate authentication. It could use GENI authorization, or it could expose some data without authentication; arguably this data should not require authentication. U Kentucky will explore this variable authentication. Currently, available data is not sufficient.
    • Ideally aggregates would expose their own data about usage and liveness
    • The set of tests and the possible aggregate states to expose are TBD. End-to-end tests are most authoritative, but should be done by a single tool that shares results with others. Other measures include the fraction of reservations that fail, whether a known image boots on a resource, scheduled downtime, etc.

  • Rob Ricci indicated that over the coming months all ProtoGENI based aggregates will need their control nodes re-imaged to address some Xen instabilities. This will be done in waves by the local administrators.
  • Processes and tools for GENI developer coordination in the coming months, in the absence of a planned meeting before next spring (the next planned GEC).
    • Replace the mailing list with a Google group for discussions
    • Conduct public video conferences or conference calls as needed
      • Anyone can ask for a call/conference on the Google group, using a Doodle poll or similar to schedule. For a given topic, the set of required people will vary; all community members are welcome and encouraged to participate.
      • A designated participant on each call should keep records of decisions and key discussion points.
      • Agreement on the call constitutes agreement by the community.
      • If in person meetings are necessary, Chip noted that funding might be available.
      • The attendees agreed to revisit this procedure at the next GEC and update as necessary
    • Create public pointers to software repositories and issue trackers
    • Create a general GENI issue tracker for discussions and proposals (GPO action item)

  • Tool support for Speaks For
    • GENI Desktop and the CloudLab Portal are eager to use Speaks For authorization with AL2S once Internet2 deploys the upgrade they are currently testing.
    • Nick Bastin says VTS is likely to support Speaks For, but FOAM is not.
    • GENI Portal support of Speaks For is TBD (depending on whether Portal support of FOAM is required).

  • Enhancing the Speaks For Signing tool for use as authentication mechanism:
    • University of Utah plans to add several features to allow pre-selecting the user's authority, tool-configured default credential expiration, and allow remembering the user's decision to authorize a particular tool (and an option to stop remembering).
      • A remembered decision means that with each authentication to the tool, a new Speaks For credential is generated without the user clicking 'Authorize'.
    • CloudLab and GENI Desktop and any other tools using the signing tool for authentication can use these enhancements, use browser storage to store the speaks for credential, and offer a 'Remember Me' checkbox on the sign in page.

  • Stitching schema enhancements
    • Nick Bastin will propose a series of revisions to stitching schema version 2, including advertising link support for MAC learning
  • The ProtoGENI team plans to modify ProtoGENI based advertisement RSpecs to allow requesting an external facing VLAN tag without using a stitching extension or specifying an off-the-aggregate resource to connect to.