Changes between Version 2 and Version 3 of GEC12GeniAmAPI


Ignore:
Timestamp:
11/03/11 16:16:59 (8 years ago)
Author:
Aaron Helsinger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GEC12GeniAmAPI

    v2 v3  
    2828 * [wiki:GAPI_AM_API_DRAFT Draft AM API Revisions wiki page]
    2929 * GENI developer list discussions on [http://lists.geni.net/pipermail/dev/2011-October/000403.html new options and return structures], and on [http://lists.geni.net/pipermail/dev/2011-October/000433.html Updatesliver]
     30
     31=== Meeting Summary ===
     32 * We agreed to two change sets, completing the list of changes to include in AM API version 2. We will:
     33 * Adopt change set A for inclusion in AM API version 2: RSpecs are GENI schema XML
     34 * Adopt change set B for inclusion in AM API version 2:
     35  * All methods include a new 'options' XMLRPC struct argument with no required values, supporting aggregate innovation
     36  * All methods return an XMLRPC struct consisting of (1) a return 'code', (2) the return 'value' from API v1, and (3) a human readable 'output' on errors, plus optional aggregate specific entries
     37 * Discuss details on some parts of change set B
     38  * This discussion to continue at the coding sprint
     39  * Error codes: integers? or strings? (including a specific namespace rather than the more discrete and arbitrary integers)
     40  * Supporting multiple AM API versions: How can servers do this? Multiple URLs as at ProtoGENI? If so, how do aggregates advertise those versions/URLs? (Perhaps in !GetVersion?)
     41  * How are GENI error codes documented? A wiki page?
     42  * How are new aggregate-specific options or returns documented? XMLRPC introspection? New !GetVersion entries?
     43  * Define GENI error codes
     44 * Continue discussion of !UpdateSliver, slivers and sliver groups, and the addition of tickets on the geni developer mailing list
     45  * That discussion will also continue at the Coding Sprint session
     46 * We began the discussion of tickets, hearing details of the meaning of tickets, their semantics, and their lifecycle, from Rob Ricci, Ilia Baldine (channeling Jeff Chase), and Andy Bavier
     47
     48=== Selected Discussion Points ===
     49 * Change set A (RSpecs are XML) was adopted without discussion
     50 * Change set B (new options argument and new return structure) was adopted with minor discussion.
     51  * We must agree to and document GENI error codes
     52  * Error codes were proposed as integers, with the space divided by aggregate developer. That either wastes codes or limits or both, while also hiding in a translation table whose codes these are. Why not use strings?
     53  * On errors, maybe aggregates should return the version of the API that they speak?
     54  * Some aggregates will desire to speak multiple versions of the API
     55  * ProtoGENI uses distinct URLs to allow the client to indicate to the server which version they are speaking
     56  * Servers must then advertise those URLs to clients in some standard way
     57  * Clarification: the 'output' return is human-readable and not machine parsable
     58 * !UpdateSliver turned into a discussion of how resources get partitioned between aggregates and between slivers, which led into the discussion of slivers vs groups of slivers vs slices. We postponed this discussion.
     59 * Rob Ricci focused on the lifecycle of tickets.
     60  * Tickets support two phase commit
     61  * Tickets are a promise of resources, that make the resources unavailable to others
     62  * Tickets can be further delegated
     63  * In PG tickets are for specific resources, though they could be generic
     64  * In PG reservations either wholly succeed or fail; that decision is orthogonal to the use of tickets
     65 * Ilia Baldine / Jeff Chase described tickets in Orca as a contract
     66  * Tickets are a signed contract promising future resources for a particular time window
     67  * Tickets indicate what, where, how many, and other properties, restrictions, and whether they can be delegated
     68  * Tickets can be delegated, split
     69  * The ticket holder redeems the ticket at the resource provider to get the resources
     70  * Tickets may be for generic or specific resources
     71  * Tickets name the resource provider (the AM), which allows brokers.
     72  * Brokers allow aggregates to concentrate power, to collaborate on policy, etc
     73 * Larry Peterson expressed some concern with tickets because they are a promise, and all allocations are only best-effort in !PlanetLab
     74 * Andy Bavier of !PlanetLab described a desire to use tickets for future reservations
     75  * They are just experimenting with tickets now
     76  * They have no need for coordinated reservations
     77  * They do not want tickets mandated in the API because it adds overhead for them