GEC 25 Developer Roundtable

This is an informal session for GENI developers to discuss topics of interest to the attendees. These topics may include details of software integration, software issues that affect multiple control frameworks, or common tools.

Schedule

• Wednesday March 15 11:00 a.m. - 12:30 p.m.

Session Leaders

• Nick Bastin, Barnstormer Softworks

Agenda / Details

This software development session provides an opportunity for GENI developers to collaborate informally.

Proposed Topics:

• GENI Software Transition (Tom Mitchell)
  • GENI Portal & Clearinghouse on Amazon Web Services
  • Identity Provider transition
  • GPO-developed code
• API Additions (Nick Bastin)
  • PerformAggregateAction - same semantics as PerformOperationalAction (POA), but performed on an aggregate for a user (instead of a sliver). We currently use this functionality in VTS to link user credentials to dropbox accounts (VTS supports moving data to your dropbox from your topologies, thus making it possible to get measurement data out of topologies that are otherwise completely isolated)
  • PerformOperationalBatch - a generic mechanism to allow the contents of many POA requests to be passed in one transaction with the AM
  • SetDeleteLock POA - An optional API, but might be good if it was documented for people who wanted to implement it. This POA allows anyone with a slice credential to set a reference-counted lock on the sliver, so it cannot be deleted until they remove their lock. This prevents accidental deletions when multiple users of the same sliver miscommunicate on when they are done with it. Anyone with a valid slice credential can set the lock, and the sliver is not deleted until all locks are removed.
• Credentials (Nick Bastin)
  • GPO CH support for issuing Project credentials. We would like the clearinghouse to issue a credential of type "Project" to users with LEAD and ADMIN role (or everyone, and just put the role in the credential), so that they can take this credential to an AM to apply policy for their entire project. This is essential for PIs to be able to actually take responsibility for members of their projects proactively (rather than just being the person you call and yell at later), and would be particularly useful for classroom environments. Emulab CH supports this, but for a lot of complicated reasons we haven't been able to use it. Example uses:
    • Limit how many slices a member can use at an aggregate
    • Limit how many resources a member can use at an aggregate
    • VTS is capable of allowing PIs to enable/disable "dangerous" features, like allowing their members to disable STP in a sliver (which can be disastrous if you don't know what you're doing). Right now we manage this by hand.
    • VTS tracks all user actions in SQS queues (AM API actions as well as SSH), and this can be very useful data for instructors in classroom situations, but we don't know who owns the project so we have to be involved by hand to set it up.