Changes between Version 3 and Version 4 of GEC25Agenda/DeveloperRT


Ignore:
Timestamp:
03/11/17 14:23:48 (7 years ago)
Author:
nick.bastin@gmail.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC25Agenda/DeveloperRT

    v3 v4  
    2222  * '''!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)
    2323  * '''!PerformOperationalBatch''' - a generic mechanism to allow the contents of many POA requests to be passed in one transaction with the AM
     24  * '''!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.
     25 * Credentials (Nick Bastin)
     26  * 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:
     27   * Limit how many slices a member can use at an aggregate
     28   * Limit how many resources a member can use at an aggregate
     29   * 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.
     30   * 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.